A person who is named as an AI supervisor but lacks the time, information or authority to stop the system is not exercising meaningful oversight. Aviation law offers a practical way to test whether human control is real: identify the function being delegated, define its limits, equip the responsible person to monitor it, and preserve the ability to intervene and learn.

For high-risk AI systems, Article 14 of the EU AI Act sets an operational standard. It requires systems to be designed for effective human oversight during use, with measures proportionate to risk, autonomy and context. The system must enable assigned people to understand its capabilities and limitations, monitor for anomalies and unexpected performance, recognise automation bias, interpret outputs, decide not to use or to override them, and intervene or stop the system. These Chapter III duties take effect on a staggered schedule, discussed below.

Those are demanding outcomes. They are also familiar to aviation. Pilots do not establish command by sitting in a cockpit while an automated system operates. Command depends on knowing what mode the automation is in, understanding its operating limits, cross-checking consequential indications, and having a usable procedure when performance departs from expectation. Checklists, callouts, recurrent training and incident review turn the abstract idea of supervision into conduct that can be performed and examined.

The analogy has limits. AI providers and deployers are not aircraft pilots, and aviation rules do not automatically govern an AI product. Responsibility in aviation is itself distributed among manufacturers, operators, maintenance organisations, regulators and flight crews. Its useful lesson is that responsibility can be allocated across a system without disappearing. Each participant should answer for the part of the operation that participant controls.

Six conditions for retained command

Aviation command principles can be translated into six conditions for lawful and responsible cognitive delegation, including domain competence. That competence matters: a person cannot independently verify or safely override work in a field the person is not equipped to assess.

First, bounded authority defines what the system may do, with which data, for whom and within what limits. A drafting assistant may prepare a first-pass summary; it should not silently become the final decision-maker on a client’s rights. Permission limits, approval gates and clear escalation points are practical ways to keep the task inside its authorised envelope.

Second, domain competence makes oversight more than a job title. Article 26(2) expressly requires deployers to assign human oversight to natural persons with the necessary competence, training, authority and support. In practice, the reviewer also needs time, access to relevant information and training in the system’s known limits and likely failure modes. A reviewer who is expected to check a legal conclusion should be able to test its sources and reasoning, not merely read a confidence score.

Third, independent verification separates a model’s assertion from evidence that supports action. For consequential legal work, that can mean checking cited authorities against primary sources, confirming dates and figures against records, and testing a recommendation against the governing instructions and facts. This is a governance recommendation across many uses, not a general, standalone two-person verification rule in Article 14. The Act does impose a specific safeguard for high-risk remote biometric identification: before an action or decision rests on the identification, it must be separately verified and confirmed by at least two competent, trained and authorised people.

Fourth, meaningful intervention requires a real choice. Article 14 requires oversight measures that enable a person to reject an output, override or reverse it, and intervene or stop the system. Organisations should therefore test whether the stop mechanism works, who can use it, what happens to work already in progress, and whether an interruption can be made safely. A nominal override that takes too long, requires unavailable permissions or carries an unmanageable penalty is not practical command.

Fifth, auditability preserves a usable account of what happened. The Act’s Article 12 requires technical logging capabilities for high-risk systems, and Article 26(6) requires deployers to retain automatically generated logs under their control for at least six months, subject to other applicable law. A sound operational record should let a reviewer reconstruct the task, relevant system version, inputs, material outputs, human checks, overrides and resulting action, while respecting confidentiality and data-protection rules.

Sixth, remedial learning turns an error into a change in practice. The Act contains monitoring and incident-reporting duties for specified actors and circumstances. An organisation can make that work through a clear path for reporting failures and near misses, investigating what contributed to them, correcting procedures or permissions, and checking that the correction worked. The broader learning cycle is a governance recommendation; the Act does not impose one undifferentiated learning programme on every AI user.

A timetable that rewards preparation

The timetable requires precision. The AI Act’s general application date was 2 August 2026, but not every obligation began on that date. AI-literacy duties have applied since 2 February 2025, and Article 50 transparency obligations apply from 2 August 2026, subject to a transition until 2 December 2026 for certain providers of systems already on the market to meet the machine-readable marking duty in Article 50(2). Regulation (EU) 2026/1744, which entered into force on 27 July 2026, amended Article 113: the Chapter III requirements for high-risk systems classified under Article 6(2) and Annex III apply from 2 December 2027; those for Article 6(1) and Annex I apply from 2 August 2028. The high-risk schedule is not a reason to postpone design and procurement work.

Nor is every AI tool used by a solicitor automatically a high-risk system under the Act. Classification depends on the statutory definitions and use cases, including Annex III and its qualifications. The Act’s high-risk oversight duties operate alongside professional, confidentiality, data-protection, consumer and sector-specific obligations. A firm should classify the actual use before deciding which legal requirements apply.

For solicitors, technology companies and compliance teams, the practical starting point is a short command brief for each consequential use: What work is delegated? Who owns the decision? What is outside the system’s authority? What expertise and independent check are required? Who can pause or reverse the process? What record is kept, and how will an error change the next version of the workflow? Those questions turn “a human is in the loop” into a testable allocation of authority.

The aim is not to force people to perform every cognitive step manually. Aviation depends on automation. It also insists that automation operate within a system where human responsibility remains visible and effective. In the same way, the EU AI Act’s oversight duties will be meaningful only when the person assigned to oversee a high-risk system can understand its operation, question its output and act before harm becomes difficult to reverse.

That is the central argument of Delegated Cognition: Legal Authority, Responsibility, and Command in the Age of Autonomous Systems, Second Edition Revised and Expanded. Its aviation-law framework treats delegation as compatible with innovation, provided that authority remains bounded and an identifiable human or institution retains command.

Daniel J. Schendzielos, J.D., Ph.D., is a Colorado attorney, adjunct professor at the University of Denver Sturm College of Law and a pilot and flight instructor. He is the author of Delegated Cognition.