What I learned about the limits of artificial intelligence at TUM

Why this programme mattered to me

I attended the TUM Institute for Advanced Study summer school “Limits of Artificial Intelligence” through Erasmus+. The programme brought together lectures, group discussions, and academic visits at TUM-IAS, the Deutsches Museum, and the Leibniz Supercomputing Centre. It was valuable to me both academically and personally: I was studying a field I actively work with while learning alongside an international group of students, researchers, and lecturers.

I arrived with a mainly technical view of limits: compute, data, hardware, model capability, and the boundaries of an implementation. The programme expanded that view. I worked through logical, theoretical, physical, quantum, philosophical, ethical, legal, and societal limits. Some of those limits can be pushed through better engineering; others cannot be solved by adding more compute because they concern what a system can know, what society should permit, or which trade-offs people are willing to accept.

That distinction matters to how I build systems. It prevents me from treating every difficult problem as an optimization problem. Sometimes the right response is a smaller model, a better architecture, or more efficient hardware. Sometimes the right response is to change the objective, keep a human decision, or ask whether the system should exist in that form at all.

AI is software running on physical systems

One idea I kept returning to was that AI is never only software. Every model depends on data centres, electricity, cooling, semiconductor production, raw materials, networks, and the people who operate that infrastructure. The environmental and societal limits of AI therefore depend not only on a model's architecture, but also on where and how it runs.

The discussion of water made this concrete. Direct water use can occur at the data centre, especially through cooling. Indirect water use appears elsewhere in the lifecycle, including electricity generation, semiconductor manufacturing, and materials processing. A single universal figure for the water footprint of an AI request is therefore misleading: the result changes with the model, workload, location, cooling design, electricity mix, and the boundary used for the calculation.

The distinction between efficiency and sufficiency became one of my most useful takeaways. Efficiency asks how I can perform the same task with fewer resources. Sufficiency asks whether that computation is needed at all and how much is enough. In practical software engineering, that can mean routing a simple request to a smaller model, limiting unnecessary context, using a deterministic lookup, or avoiding generative AI where a simpler system already solves the problem reliably.

Philosophy as an engineering tool

I found the philosophical perspective especially useful. Before implementation, I already try to define the problem, constraints, and expectations. The summer school pushed me to go further: to question what key concepts mean, which assumptions remain hidden, whether two requirements are internally compatible, and who has the authority to decide when the system is “good enough”.

I now see this as practical engineering work rather than an abstract layer added after development. Clearer concepts can expose technical, ethical, or operational contradictions before they become expensive design decisions. If a team cannot agree on what autonomy, fairness, explanation, safety, or responsibility means in a particular system, implementation will not remove that ambiguity; it will encode it.

The ethical discussions reinforced a related boundary: technical capability does not automatically justify deployment. Systems used in healthcare, hiring, surveillance, or other consequential settings raise questions about bias, transparency, consent, proportionality, and accountability. In such cases, responsible engineering requires an explicit human and institutional answer to “should we?”, not only a technical answer to “can we?”.

From supercomputing to robotics

The visit to the Leibniz Supercomputing Centre was the strongest technical part of the week for me because it connected the lectures with infrastructure at a scale that cannot be ignored. I saw the systems around SuperMUC-NG, warm-water cooling, automated tape libraries for long-term research data, the Euro-Q-Exa quantum system, and work connecting classical high-performance computing with quantum computing.

I already had a strong interest in HPC, infrastructure, and AI workloads. Seeing those systems in person made the physical constraints of computation more immediate. Performance does not exist separately from power, cooling, storage, reliability, hardware lifecycle, and operational design. A benchmark can show that a system is faster, but responsible engineering also asks what resources produced that result and whether the improvement is useful enough to justify them.

At the Deutsches Museum, I connected current debates about AI with the history of computing, aviation, space exploration, autonomous systems, and humanoid robotics. That historical context made current claims about intelligence and autonomy easier to evaluate critically. Many technologies that now look inevitable were shaped by earlier design choices, social priorities, failures, and limits.

Completing the academic work

The programme did not end when I left Munich. I continued preparing for the assessment and focused on “Ethical Limits of AI”. On 21 September 2026, I completed a 30-minute online oral examination with Prof. Dr. Stefania Centrone and Dr. Andrea Reichenberger. I earned 3 ECTS and received a grade of 2.0 in the German grading system.

Preparing for the examination forced me to turn a broad week of lectures and visits into clear arguments I could explain in my own words. I had to distinguish theoretical from practical limits, efficiency from sufficiency, water withdrawal from water consumption, and technical feasibility from social acceptability. That consolidation was as valuable as the examination result.

What I took home

“Responsible engineering starts by identifying what kind of limit I am actually facing.”

• I will treat AI systems as complete physical and operational systems, not as isolated model endpoints.
• I will use the least resource-intensive solution that still meets the required quality and reliability.
• I will separate limits that better engineering can reduce from limits that require governance, values, or an explicit human decision.
• I will use conceptual clarity early, before ambiguous requirements become architecture and code.

The summer school strengthened my interest in artificial intelligence and high-performance computing, but its most durable lesson was methodological. Responsible engineering begins by asking what kind of limit I am facing. Only then can I decide whether the answer is optimization, a different architecture, a smaller objective, or a boundary that should remain.