The 7 principles of the AI Act are widely called principles; the source calls them seven requirements for trustworthy AI: Human Agency and Oversight, Technical Soundness and Safety, Privacy and Data Governance, Transparency, Diversity, Non-Discrimination and Fairness, Societal and Environmental Well-Being, and Accountability. The European Commission’s High-Level Expert Group published them in 2019, and Recital 27 names the same seven as non-binding. Compliance work that holds up names all seven exactly, then maps each to a control.

Last updated: September 2026.

Where Do the 7 Principles of the AI Act Come From?

The seven requirements for trustworthy AI come from the Ethics Guidelines for Trustworthy AI, published in 2019 by the European Commission’s High-Level Expert Group on Artificial Intelligence (European Commission, 2019). The guidelines define trustworthy AI as lawful, ethical and reliable in practice, then break the ethical part into seven requirements a system should meet across its lifecycle. Peer-reviewed legal analysis traces those seven back to four foundations: respect for human autonomy, prevention of harm, fairness and explicability (European Business Organization Law Review, 2021).

One place settles the link to the Regulation. Recital 27 of Regulation (EU) 2024/1689 names the same seven and treats them as non-binding (Regulation (EU) 2024/1689, 2024). The list sits in that recital, not in a numbered article. Independent legal analysis of the European approach enumerates the same seven and describes the guidelines as a non-binding precursor to the Act (Lawfare, 2021).

Naming matters at audit time. Search traffic says principles, the guidelines say requirements, and both point to the same seven items. An answer that renames one, drops one, or invents an eighth is wrong on the record a regulator will read. Get the provenance right first, then argue about controls.

The Seven Requirements, Named in Order

Here is the list as the guidelines set it out, with what each one asks of an organization that deploys AI rather than builds it.

1. Human Agency and Oversight. AI supports human autonomy and decision making rather than displacing it. A named person can understand what the system is doing, intervene, and reverse an action. For deployers, the load-bearing word is oversight while the system runs, not sign-off before it launches.
2. Technical Soundness and Safety. Resilience to attack and misuse, a fallback plan, accuracy, reliability and reproducibility. In practice this is where prompt injection, tool poisoning, unsafe generated code and destructive tool calls sit.
3. Privacy and Data Governance. Respect for privacy, data quality and integrity, and controlled access to data. It covers what enters a prompt or an agent’s context, what leaves in a response, and who inside the organization can see either.
4. Transparency. Traceability, explainability and communication. People know when they are dealing with AI, and the data, processes and decisions behind an output can be reconstructed after the fact.
5. Diversity, Non-Discrimination and Fairness. Avoidance of unfair bias, accessibility and universal design, and stakeholder participation. Operational evidence should show how teams test outcomes for bias, review accessibility, involve affected stakeholders, and address unequal effects.
6. Societal and Environmental Well-Being. Sustainability, social impact, and effects on democratic process and the workforce. For most enterprises this shows up in vendor selection, data retention posture and the working conditions AI creates for staff.
7. Accountability. Auditability, reporting of negative impacts, documented trade-offs and a route to redress. Accountability is the requirement that turns the other six into something an outsider can inspect.

Are the Seven Principles Legally Binding?

The seven are not binding as a list. Recital 27 presents them as non-binding requirements for trustworthy AI, and Article 95 provides for codes of conduct covering voluntary application of requirements to AI systems other than high-risk ones (EU AI Act Article 95, 2024). Binding duties come from separate articles, and each applies according to the system, the use case and the regulated actor.

The Act uses a risk-based structure. It prohibits defined practices, sets detailed obligations for high-risk systems, applies transparency duties to certain systems and content, addresses general-purpose AI models separately, and requires AI literacy measures. The seven run underneath that structure. Where a requirement became law for a defined system, it appears as a specific article with an evidence trail attached, not as a direct restatement of the requirement itself.

Human oversight shows the translation most clearly. Article 14 requires high-risk systems to be designed so natural persons can oversee them effectively (EU AI Act Article 14, 2024). A separate provision on deployer obligations requires assigning that oversight to people with the competence, training and authority to act.

Outside the high-risk tier, obligations do not simply stop. Transparency duties apply to certain systems and to specified AI-generated content, general-purpose AI model provisions apply to model providers, AI literacy measures apply broadly, and law outside the Act, including data protection and employment law, still applies. The seven-part list is non-binding. A corresponding article binds when the system, use case and regulated actor fall within that article’s scope. The practical gap opens where nothing binding attaches: a requirement written into internal policy that nothing enforces produces no evidence when someone asks for it.

Mapping Each Requirement to an Operational Control

Most published treatments of the seven stop at definitions. A useful version keeps going in two directions: which legal mechanism and lifecycle stage each requirement maps to under the Act, and where interaction-layer controls supply operational evidence. The two are related, not identical.

Two further provisions anchor the rows below. Article 10 sets data and data governance requirements for specified high-risk systems (EU AI Act Article 10, 2024). Article 12 requires automatic record keeping for high-risk systems throughout their lifecycle (EU AI Act Article 12, 2024). Three rows rest on provisions not hyperlinked here and need a check against the official text before publication.

The legal mapping shows where a duty attaches. The next table sets a typical assurance activity beside what Aurascape contributes at the interaction and agent-execution layer, where the legal mapping runs out of operational detail. Aurascape enforces policy inline with allow, coach, notify, redact, redirect, and block actions, classifies data in the exchange as it moves, and governs tool calls made over the Model Context Protocol (MCP) at the point of execution (Aurascape, 2026). That contribution is strongest for Human Agency and Oversight, Technical Soundness and Safety, Privacy and Data Governance, Transparency, and Accountability. For Diversity, Non-Discrimination and Fairness, and for Societal and Environmental Well-Being, interaction-layer evidence supports governance work but does not carry the requirement; bias testing, accessibility review, outcome monitoring and vendor disclosure do.

Nothing in the second table substitutes for the duties in the first. It shows where runtime evidence exists to support them.

Why Does AI Discovery Come Before Runtime Governance?

Applying the seven requirements to systems in use starts with an accurate inventory of AI apps, accounts and agents. That inventory breaks first. Employees adopt tools directly, coding assistants arrive as IDE extensions, AI features ship inside existing SaaS, and agents run locally on laptops. Aurascape maintains a continuously updated catalog of 30,000+ AI apps and agents and has detected 50+ new AI apps releasing daily, with discovery running across network, endpoint and API planes (Aurascape, 2026). The endpoint agent detects an agent launch and its configuration, including MCP server connections, before the agent takes its first action.

Discovery is not an inventory exercise dressed up as governance. It decides whether the other controls reach every business unit consistently. Privacy and data governance work depends on knowing whether a session runs under an enterprise tenant or a personal account, because the applicable retention and confidentiality terms differ by service and plan. Teams only ask vendor questions about a tool’s data practices once the tool is on the list. Data leaks are now the top generative AI security concern at 34%, ahead of advancement of adversarial capabilities at 29%, reversing the 2025 ranking (World Economic Forum, 2026).

Sector obligations then layer on top of the seven. Compliance leaders can start with our guide to AI compliance frameworks for enterprise AI, and the sector versions for financial services and for healthcare and pharmaceutical organizations.

Applying the Requirements at the Agent-to-Tool Step

Oversight, safety and accountability get hardest the moment an agent stops generating text and starts acting: reading a record, writing to a ticket, calling an internal service. MCP is one common tool-execution pattern, not the whole agent access-control problem, since agents also act through APIs, browsers, command line interfaces and vendor plugins, and controls have to follow them there.

Aurascape discovers and secures local AI agents and their interactions, and adds a Zero-Bypass MCP Gateway that marks every tool call it approves and blocks unmarked calls, governing the agent-to-tool execution path inline rather than observing it (Aurascape, 2026). Agent interactions run on two channels. The intelligence channel connects the agent to the model and is secured by the AI Proxy. The tool-execution channel connects the agent to MCP servers and is secured by the Gateway. Because the platform sits on both, a call that skipped the Gateway surfaces on the model path and is stopped before the model acts on the result.

That turns Technical Soundness and Safety from a testing report into an enforced condition. OWASP ranks prompt injection (LLM01), sensitive information disclosure (LLM02) and excessive agency (LLM06) among the top risks in its Top 10 for LLM Applications (OWASP, 2025). All three surface during live use, where interaction context and tool-call evidence help teams detect and govern the resulting risk: instructions hidden in a retrieved document, a tool description changed on the server side after sanction, or a chained read-then-write sequence that moves sensitive records out through a second tool.

Accountability lands in the same place. Only 28% of organizations can trace agent actions back to a human sponsor across all environments (Cloud Security Alliance, 2026). Aurascape keeps interaction records for audit and effectiveness, governed by role-based access control (RBAC) for privacy, covering the user identity, application, server, tool, parameters, detected data categories, detected threat categories and the policy action taken. An auditor can test that level of detail against a named requirement.

Teams that want an official starting point can use the Assessment List for Trustworthy AI (ALTAI), which turns the same seven into a self-assessment questionnaire with question sets per requirement (European Commission, 2020). It is a self-assessment instrument rather than a conformity assessment, so its output works as an internal governance input alongside the documentation and record keeping the Act requires for systems in scope.

A working sequence for turning the seven requirements into evidence, in the order that produces results fastest:

1. Inventory the real estate. Discover AI apps, embedded AI features, coding assistants, MCP servers and local agents in use, including the long tail nobody filed a ticket for.
2. Separate accounts from applications. Distinguish enterprise tenants from personal accounts, then check the terms that apply to each, because they drive the privacy and data governance answer.
3. Write policy against tags, not app names. Group applications with tags so new tools inherit the rule set when tagged, instead of accumulating exceptions that break consistency.
4. Set data rules inside the interaction. Classify prompts, files, code and tool results in real time, then choose the action per case: allow, coach the user, notify, redact the value, redirect to the enterprise tenant, or block.
5. Govern the tool-execution path. Sanction tools individually, bind access rules to users and groups, hold high-risk write and execute calls for human confirmation, and block anything that arrives unmarked.
6. Decide the failure behavior deliberately. Policy configuration determines whether traffic on paths the platform does not decode fails open or fails closed. Record that decision, because it is a governance choice under human oversight.
7. Produce evidence per requirement. Map the interaction records to each of the seven, and keep the mapping current as new tools and agents appear.

Frequently Asked Questions

Are the seven principles legally binding under the AI Act?

Not as a list. Recital 27 presents them as non-binding, and Article 95 provides for codes of conduct covering voluntary application of requirements to systems other than high-risk ones. Several of the seven became binding duties for high-risk systems, appearing as articles on risk management, data governance, technical documentation, record keeping, transparency, human oversight, and accuracy, resilience and cybersecurity. Which duty applies depends on the system, the use case and the regulated actor.

Where do the seven principles of the AI Act come from?

They trace to the Ethics Guidelines for Trustworthy AI, published in 2019 by the European Commission’s High-Level Expert Group on Artificial Intelligence. The guidelines call them requirements; most search traffic calls them principles; Recital 27 of the AI Act names the same seven and treats them as non-binding.

How do the seven relate to the Act’s risk tiers?

The risk tiers decide how much of each requirement binds, and which actor it binds. Prohibited practices are ruled out entirely. High-risk systems carry detailed obligations split between providers, who hold design and documentation duties, and deployers, who hold duties such as assigning competent human oversight. Other systems carry targeted transparency duties, and general-purpose AI models are addressed separately.

What evidence shows a regulator that we apply the seven?

Records of what actually happened, tied to a named control and a named actor. Useful evidence names who used which AI application and under which account, what data was involved, what the system returned, which tool was invoked, what policy decision was made, and what record remains. Policy documents establish intent; interaction records establish practice.

Which requirement covers AI agents that call tools?

Three of them at once. Human Agency and Oversight covers the ability to intervene in an agent’s action, Technical Soundness and Safety covers manipulation of the agent through injected instructions or altered tool definitions, and Accountability covers the audit trail for every call. Governing the agent-to-tool execution path inline is one control that serves all three, alongside design-time testing and evaluation.

Is there an official checklist for the seven principles?

Yes. The Assessment List for Trustworthy AI (ALTAI) is the European Commission’s self-assessment tool built around the same seven requirements, with question sets for each. It is a self-assessment instrument rather than a conformity assessment, so pair its output with the technical documentation, record keeping and human oversight evidence that binding provisions require for systems in scope.

Do the seven apply to AI tools employees adopt on their own?

The seven inform internal policy for any AI in use. Whether a specific legal duty attaches depends on the system, the use case, the organization’s role and other applicable law such as data protection rules, so treat unsanctioned adoption as a question for counsel rather than an automatic obligation. Either way, the practical starting point is the same: discover the AI apps, accounts and agents actually in use, because nothing else applies consistently without that.

Aurascape gives compliance teams interaction-layer evidence for the requirements that depend most on runtime visibility: Human Agency and Oversight, Technical Soundness and Safety, Privacy and Data Governance, Transparency, and Accountability. That means discovery of AI apps, accounts and agents in use, real-time classification of the data moving through each interaction, inline enforcement with allow, coach, notify, redact, redirect, and block, and zero-bypass governance of agent tool calls, all captured as interaction records a compliance team can map to a specific requirement. Fairness and societal well-being still need evidence from outside the interaction layer. Book a demo to see how the mapping applies to your own AI estate.

See how Aurascape maps the seven trustworthy AI requirements to enforced controls →