What EU AI Act Article 13 requiresin plain English

Our compliance lawyer sent me a 40-page PDF on EU AI Act Article 13. Here is what it actually says, stripped of the footnotes, formatted so you can tell your engineer what to build, and honest about the parts where you still need qualified legal counsel.

Article 13 is the transparency article. It applies to providers and deployers of high-risk AI systems and it has been enforceable since August 2026 for new systems. The core ask is simple: if your system makes consequential decisions about people, those people, and the organizations overseeing them, must be able to understand how.

Article 13 targets high-risk AI systems. The EU AI Act defines this category in Annex III. The list covers AI used in critical infrastructure, education, employment, essential services, law enforcement, border management, justice, and democratic processes. If your system makes hiring decisions, credit determinations, or influences access to healthcare or education, it almost certainly qualifies.

Two roles matter here. The provider builds and places the system on the market. The deployer uses it in an operational context. Both carry obligations. Providers must build transparency in. Deployers must operate it transparently and cannot delegate that responsibility to a vendor.

If you are building an AI product that enterprises will deploy against their employees or customers, you are likely the provider. Your enterprise customers are the deployers. Both of you need to read this.

The article requires that high-risk AI systems be designed to allow deployers to correctly interpret the system's output. That sounds vague. The actual requirements break into three buckets: instructions for use, capability disclosure, and logging. Each has specific sub-requirements.

Article 13 is organized as five specific obligations. Here is each one, in plain language.

The audit trail in kavachOS records every agent action, every authentication event, and every permission change, with full timestamps, actor identity, and delegation chain. Here is how that maps to each Article 13 sub-rule.

The gap at 13.3b is deliberate. kavachOS handles identity and authorization. Model performance benchmarks, known failure modes, and bias disclosures come from your model infrastructure or your AI system documentation. We log who called what and when. We do not instrument the model itself.

kavachOS covers the auth and delegation layer. Article 13 compliance for a real high-risk AI system is broader. The remaining pieces are yours to build.

• Instructions for use document. Article 13.2 requires a written document that goes to deployers. kavachOS does not generate this for you. It needs to describe your system's purpose, limitations, and oversight requirements in language a non-technical deployer can act on.
• Model performance disclosure (13.3b). If your system has known demographic or geographic performance gaps, those must be disclosed. This comes from your evaluation pipeline, not from your auth layer.
• Incident reporting process. Serious incidents involving high-risk AI must be reported to national authorities within 72 hours. kavachOS anomaly detection can surface signals, but your organization needs a defined escalation path and a designated point of contact.
• RBAC policy for human oversight. Article 13 requires that human oversight is possible. Use kavachOS RBAC (see the RBAC docs at docs link below) to define which roles can review, override, or pause AI decisions. Those override actions then appear in the audit trail.
• Data governance alignment. The audit logs contain personal data in the form of user IDs, agent IDs, and request metadata. Your organization's data governance and GDPR program applies to those logs as it would to any personal data store.

The permissions model covers role assignments in detail. If you are managing compliance-relevant roles from an identity provider, the SCIM provisioning feature handles that automatically.