Council of Europe AI Convention: What the Treaty Requires and What It Does Not

The Council of Europe Framework Convention on Artificial Intelligence and Human Rights, Democracy and the Rule of Law binds parties at the treaty level. It tells governments what results their legal systems must produce. Domestic law and regulation determine what a particular company must do, alongside enforcement mechanisms.

That allocation changes the compliance question. An enterprise should identify the treaty's recurring evidence demands, map them to laws that already apply, and preserve records that can support future domestic measures. Copying the convention's articles into a control register leaves that work unfinished.

TL;DR

• The convention binds states and the European Union after consent to be bound and entry into force. It does not itself create a universal enterprise checklist.
• Public-sector AI is directly within scope. Each party chooses how to address private-sector risks, subject to its existing human-rights obligations.
• Articles 14 to 16 connect remedies, contestability, notice, risk management, testing, monitoring, and documentation.
• Enterprises should preserve decision context and policy evidence now, without claiming that logs alone satisfy the treaty.

The mandate sits with governments

Article 3 draws the first boundary. Activities by public authorities are within scope, along with activities by private actors acting on their behalf. For other private actors, each party must address AI risks in a way that conforms with the convention's object and purpose. A party may apply Chapters II to VI to private actors or use other appropriate measures, and it must explain that choice in a declaration.

This allocation means two companies deploying the same model in different countries may encounter different implementing measures. One state could extend the convention's principles through horizontal AI legislation. Another could rely on privacy and equality rules, consumer-protection law, administrative law, or sector rules. The convention supplies a common destination while national law sets the route.

The public and private distinction can also move with the contract. A vendor operating an eligibility model for a ministry is a private actor acting on behalf of a public authority. The same vendor running an internal productivity assistant is not automatically in that category. Ownership of the model is less important than the activity and whose authority it serves.

Article 30 supplies a second boundary. Signature is followed by ratification or acceptance, with approval as another route, and the treaty has its own entry-into-force test. The UK government's signing announcement made the implementation sequence explicit: domestic laws and measures would be addressed as the convention was ratified. A signing announcement therefore should not be treated as proof that every provision already binds every private deployer.

The principles are broad, but the evidence questions are concrete

Articles 7 through 12 cover human dignity and autonomy, transparency and oversight, accountability, equality and non-discrimination, privacy and personal-data protection, and reliability. Those headings sound like policy language because parties retain discretion over implementation. The operational questions beneath them are familiar:

• Which AI system affected the person or process?
• What purpose and context governed its use?
• Who was accountable for the decision?
• What oversight applied at the time?
• Which risks were identified and monitored, and how were they addressed?
• What information can an affected person or competent authority obtain?

A written principle cannot answer those questions after the fact. An AI governance framework needs system ownership and decision records beneath the policy layer, supported by review paths and evidence retention.

Article 8 is a useful example. It requires transparency and oversight measures tailored to context and risk, including measures concerning identification of AI-generated content. It does not prescribe one disclosure label or watermarking standard. Nor does it prescribe one log schema. A domestic rule can make those requirements specific. Until then, a company should record where AI is used and who receives its outputs. The record should also show which disclosure or review control applies to that use case.

Article 16 turns principles into a risk-management cycle

Article 16 is the convention's clearest operating model. Parties must adopt or maintain measures for identifying, assessing, preventing, and mitigating actual and potential effects on human rights, democracy, and the rule of law. The measures must be graduated to context, intended use, severity, and probability.

The article then names the parts of the cycle that matter. Risk work should consider affected stakeholders and continue throughout the system lifecycle. It should monitor adverse impacts, document risks and the chosen response, and include testing before first use and after significant modification where appropriate. Parties must also consider bans and moratoria, among other measures, for uses incompatible with human rights, democracy, or the rule of law.

For an enterprise, the defensible response is not to invent a "Council of Europe certified" assessment. It is to connect the treaty themes to the risk processes the organisation already operates. An impact assessment should name the use case, affected groups, decision consequences, and system dependencies. It should also capture test evidence, residual risk, control ownership, approval, and the review trigger. That structure also supports adjacent requirements such as the EU AI Act compliance programme, while keeping the legal bases separate.

A model replacement, a new retrieval source, a change to an agent's tools, or removal of human review can invalidate the approved assessment. Article 16 treats lifecycle risk management as iterative. A useful control links those material changes to reassessment rather than relying on an annual calendar alone.

Remedies require more than an internal audit log

Article 14 requires measures supporting accessible and effective remedies for human-rights violations. It calls for relevant information about systems that can significantly affect human rights to be documented and supplied to authorised bodies. Where appropriate, that information should also reach affected people. It must be sufficient for them to contest decisions made or substantially informed by the system, and they must have an effective route to complain to a competent authority.

This is where a narrow logging claim fails. A gateway record may show that a model call occurred and which identity initiated it. It may also show what policy applied and whether the request was allowed. That evidence can help reconstruct the technical event. It does not by itself explain the substantive reason for a benefits denial or provide a complaint channel. Nor does it establish a legal remedy.

Article 15 reinforces the difference. It calls for procedural safeguards where AI significantly affects human rights and, where appropriate, notice when a person is interacting with AI rather than a human. Notice belongs in the product or service interface. A complaint route belongs in the organisation's process. Decision reasons may require application data and model outputs, supported by human review notes and governing criteria. The AI audit-trail requirements reference is useful for designing the evidence layer, but evidence is one component of a remedy system.

This also prevents a common category error with automated decisions. The convention's remedy and safeguard provisions should be mapped alongside applicable domestic rights, not substituted for them. In Europe, teams may also need to assess GDPR Article 22 and automated decisions. The tests and legal effects are different even when the same decision record supports both reviews.

What to preserve before domestic rules settle

The convention leaves implementation choices to parties, but it makes weak evidence a poor bet. A practical evidence baseline should cover:

• the system and model, including the version, owner, purpose, and deployment context;
• whether the activity is public or wholly private, including work performed for a public authority;
• the people and rights that may be affected;
• risk and impact assessments, supported by test results, approvals, and residual-risk decisions;
• significant modifications and the reassessment they triggered;
• the identity of the user or service behind consequential AI interactions, including an agent where applicable;
• the policy state and oversight path in force when a decision occurred;
• monitoring findings and incidents, including remediation and control exceptions;
• notices and human-review routes, including reasons and complaint handling where applicable.

Not every system needs the same retention period or depth. A drafting assistant and an eligibility engine do not carry the same consequence. Article 16 supports that difference by requiring graduated measures. The record should be proportionate without becoming so thin that no one can reconstruct what happened.

The resulting control set should also identify gaps honestly. Request-path telemetry cannot prove training-data provenance or fairness of a source dataset. It also cannot prove accessibility of a complaint procedure or independence of an oversight body. Those facts live elsewhere. A mature evidence map says which system owns each fact and how an investigator can retrieve it.

DeepInspect

DeepInspect addresses one bounded part of this evidence problem. It sits on the HTTP path between authenticated users or agents and model providers. It applies identity-aware policy to requests and responses, then records the resulting decision. That can preserve who invoked which model and the policy state that applied. It also preserves the enforcement outcome. Those records can support an Article 16 risk review or help reconstruct an interaction relevant to Article 14.

It cannot ratify or implement the convention. It cannot decide whether a use violates human rights, provide a legal remedy, render an end-user notice, or replace a human-impact assessment. Those responsibilities remain with governments and legal owners, supported by product teams and oversight functions. If you are mapping treaty-level AI principles to enforceable controls and inspectable evidence, a technical review can show which request-path records are available.

Book a technical deep dive at deepinspect.ai.