What AI can and cannot do

AI is often discussed as if it were a single kind of intelligence. It is more useful to ask what a particular system is being asked to do, what evidence it can access, and what happens when it is wrong.

Pattern is not understanding

Many AI systems are very good at finding regularities in examples. A model can classify an image, predict a likely next word, rank a search result, or recommend an item because similar patterns appeared in its training or operating data.

That ability can be powerful without being the same as human understanding. A system may produce a fluent explanation without having checked whether its claim is true. It may identify a correlation without knowing what caused it. It may perform well on a benchmark while failing when the setting, population, language, or incentives change.

The boundary is not always visible in the output. A confident sentence can hide uncertainty; a quiet failure can look like a normal result.

The task defines the risk

A spelling suggestion and a decision about access to work, credit, healthcare, or public services are not the same kind of AI use. The more a system affects a person’s rights, opportunities, safety, or reputation, the more the organisation needs to define the task, document its limits, and provide a way to challenge the result.

Evaluation should therefore be tied to the real use case. Teams need to test error rates across relevant groups, check performance on unusual cases, and look for failures caused by missing data or changing conditions. A single average score is rarely enough.

What people still have to do

Human involvement is not meaningful simply because someone clicks an approval button. A reviewer needs enough context, time, authority, and expertise to question the output. They also need a clear escalation path when a model behaves unexpectedly.

The organisation remains responsible for choosing the objective, supplying the data, setting the threshold, deciding where the system can be used, and responding when it causes harm. These are governance decisions, not features that can be delegated to a model.

Useful systems are observable systems

Responsible deployment treats an AI product as a changing system. Inputs drift, users adapt, data pipelines break, and new contexts create errors that were not visible in a test set. Monitoring, incident reporting, version records, access controls, and the ability to pause or roll back a system are therefore part of ordinary product quality.

The most useful question is not whether AI is intelligent enough in the abstract. It is whether this system has a bounded job, a testable standard, a visible failure mode, and a person or institution prepared to take responsibility for the outcome.