Table of contents
Share This Article
- •The Deadline Moved. The Work Did Not.
- •What EU AI Act Article 13 Actually Requires
- •Which AI Systems Fall Under Article 13
- •The Mistake Most Teams Make
- •What Your Engineering Team Must Actually Build
The deadline you were racing toward just moved. On 7 May 2026, EU negotiators agreed to push the high-risk obligations under Annex III from August 2026 to 2 December 2027. If you run a high-risk AI system, you now have more time. You should not slow down. EU AI Act Article 13 technical implementation is the part of the law your engineering team owns, and it is the part that takes the longest to build. Transparency, logging, and human oversight are not paperwork you generate the week before an audit. They are product features you design in from the start. The extra months are a gift. Use them to build, not to wait.
The Deadline Moved. The Work Did Not.
The Digital Omnibus agreement reached on 7 May 2026 was the first amendment to the AI Act since it became law. It deferred the Annex III high-risk obligations to 2 December 2027 and pushed the Annex I product-embedded systems to 2 August 2028. The package still needs formal adoption, expected over the summer, so the dates could shift again at the margins. The direction will not.
Read the relief for what it is. Regulators did not weaken the requirements for high-risk systems. They gave the market time to meet them because most companies were not ready. The Council of the EU said the goal was to simplify the rules, not to lower the bar on safety, transparency, or accountability. Article 13 survived intact.
Here is the trap. A delayed deadline feels like a reason to deprioritise. For Article 13, that logic fails. The obligations under this article cannot be retrofitted in a sprint. You cannot bolt transparency onto a model after it ships. You cannot reconstruct eighteen months of decision logs that you never recorded. EU AI Act Article 13 technical implementation is foundational engineering work, and foundational work done under deadline pressure is done badly. The teams that start now will treat the next eighteen months as a build phase. The teams that wait will repeat the panic of early 2026, only with less margin.
What EU AI Act Article 13 Actually Requires
Article 13 sits inside Chapter III, the part of the EU AI Act that governs high-risk AI systems. Its title is “Transparency and provision of information to deployers.” A deployer is the organisation that puts your system to use. The article exists so deployers can understand what your system does, how well it does it, and where it fails.
The official text of Article 13 breaks into two demands. First, the system itself must be designed so its operation is transparent enough for a deployer to interpret the output and use it correctly. Second, the system must ship with instructions for use that are concise, complete, correct, and clear.
Those instructions are not a marketing sheet. The Act lists what they must contain, at minimum: the identity and contact of the provider; the intended purpose; the level of accuracy, robustness, and cybersecurity it was tested against, plus the metrics behind those claims; the known circumstances that can lead to risks to health, safety, or fundamental rights; the performance you can expect for the specific people or groups it targets; the specifications of the input data and the training, validation, and testing sets; enough information to interpret the output; the human oversight measures, including the technical features that help a person read it; the computational and hardware resources, the expected lifetime, and the maintenance schedule; and, where relevant, the logging mechanisms that let deployers collect and read the system’s records.
Every one of those items is an engineering artifact. That is the point most teams miss.
Article 13 Requirements → Engineering Deliverables: A Translation
The table below maps each minimum required element of the instructions for use to the engineering deliverable it demands and the priority you should assign it.
| Article 13 Requirement | What the Law Says | Engineering Deliverable | Priority |
|---|---|---|---|
| Provider identity | Name, registered address, contact details of the provider | Auto-populated system card field, pulled from model registry metadata at release time | P0 — trivial to add, first to ship |
| Intended purpose | The task, context, and persons or groups the system is designed for | Structured purpose statement in the system card, version-controlled alongside the model | P0 — foundational; informs all other fields |
| Accuracy, robustness, cybersecurity claims | Levels tested against, including the metrics used to measure them | Automated evaluation harness that emits accuracy, robustness (distribution shift), and adversarial test results at every release; stored in the model registry | P1 — high effort, high compliance value |
| Known risk circumstances | Foreseeable situations where risks to health, safety, or fundamental rights may arise | Structured risk register, maintained by engineering and legal jointly, linked to the system card | P1 — requires cross-functional input |
| Subgroup performance | Expected accuracy levels for specific persons or groups the system targets or affects | Disaggregated evaluation results by demographic slice; requires test set construction with subgroup labels | P1 — often the biggest gap; start data work early |
| Input data specifications | Specifications of the input data, training, validation, and test sets | Data schema, source provenance, validation rules, and dataset cards stored in the model registry and auto-linked to the system card | P1 — implement alongside evaluation harness |
| Output interpretation | Information enabling deployers to interpret the system's output and use it appropriately | Confidence/uncertainty signals, provenance trail, feature attribution or retrieved source display — built into the product UI and the API contract | P0 — cannot be added retroactively without redesign |
| Human oversight features | Technical characteristics supporting meaningful human oversight | Override controls, escalation paths, audit trail of human interventions — implemented per Article 14 requirements | P0 — required for Article 14 compliance too |
| Compute requirements and lifetime | Expected computational resources, hardware requirements, and maintenance schedule | Infrastructure specification block in the system card, updated at each release and major dependency change | P2 — important for deployer planning; easier to add once system card pipeline exists |
| Logging capabilities | Description of logging mechanisms and how deployers can collect and read logs | Event logging schema documentation, retention policy, and API for log export — included in the system card and the developer docs | P1 — infrastructure-heavy; start planning in Q3 2026 |
Which AI Systems Fall Under Article 13
Before your team builds anything, confirm that your systems actually fall under Article 13. The Act does not apply to all AI. It applies to high-risk AI systems, defined primarily through Annex III of the regulation.
The Annex III High-Risk Categories
Annex III lists eight categories of high-risk use cases. If your AI system operates in any of these areas, Article 13 applies:
- Critical infrastructure — AI managing or operating road, rail, water, gas, heating, electrical systems, and critical digital infrastructure
- Education and vocational training — systems that determine access to educational institutions, assess students, or monitor exam conduct
- Employment, workers management, and self-employment — recruitment and selection tools (CV screening, interview assessments), performance monitoring, promotion and termination recommendations
- Essential private and public services — credit scoring, life and health insurance risk assessment, public benefit eligibility, emergency services dispatch prioritisation
- Law enforcement — polygraph tools, risk assessment for recidivism or criminal offending, deepfake detection used in evidence evaluation
- Migration, asylum, border control — risk assessment of applicants, examination of travel document authenticity, processing of applications for asylum or visa
- Administration of justice and democratic processes — AI assisting in researching facts and applying law, AI influencing electoral outcomes
- Biometric identification and categorisation — real-time and post-hoc remote biometric identification in publicly accessible spaces
If your product or system touches any of these areas — even partially, even as a component embedded in a larger workflow — you are in scope.
How APAC Companies Selling into the EU Get Caught
The EU AI Act has explicit extraterritorial reach. It applies based on where the output of the AI system is used, not where the provider or developer is based. If a company headquartered in Singapore or Hong Kong deploys a high-risk AI system whose outputs affect people in the EU — EU job applicants processed by a screening tool, EU customers assessed for credit or insurance eligibility, EU residents whose data flows through a biometric system — that system falls under the regulation.
The practical implication: if you have EU customers, EU employees affected by your systems, or EU-resident data subjects, you cannot treat the AI Act as a European-only concern. Providers based outside the EU must designate an EU representative and comply with registration requirements in the EU database for high-risk systems.
General-Purpose AI Models: Articles 52 and 53 Apply, Not Article 13
One source of confusion in the market: the obligations under Article 13 are for high-risk AI systems, not for general-purpose AI models (GPAIs). GPAIs — the large foundational models from providers like OpenAI, Anthropic, or Google DeepMind — are governed separately under Articles 52 and 53, which impose transparency obligations on model providers and, for systemic-risk models, additional requirements for adversarial testing and incident reporting.
If your organisation builds applications on top of a GPAI, you are the deployer or developer of a downstream AI system. If that system falls into an Annex III category, Article 13 applies to your system, regardless of what model powers it. You cannot push responsibility upstream to the GPAI provider — you own the instructions for use and the transparency obligations for the system you built.
How to Self-Assess Whether Your AI System Is High-Risk
Run through this checklist for each AI system in your portfolio:
- Does the system’s output influence a decision that affects a person’s access to education, employment, credit, essential services, or legal rights?
- Is the system used in law enforcement, migration processing, or democratic processes?
- Does the system perform remote biometric identification in a publicly accessible space?
- Is the system a safety component of critical infrastructure?
If the answer to any question is yes, treat the system as high-risk until a formal legal assessment says otherwise. The cost of a false negative — building a non-compliant high-risk system — is significantly higher than the cost of a false positive — applying Article 13 to a system that turns out not to need it.
The Mistake Most Teams Make
The first instinct in many companies is to hand Article 13 to legal and compliance. They read “transparency and provision of information,” they see a documentation requirement, and they assign a technical writer to produce a PDF. Six months later the PDF describes a system that no longer exists.
This approach fails for three reasons.
The instructions for use are not static. Article 13 asks you to describe accuracy metrics, performance for specific groups, and known failure modes. Those facts change every time you retrain, fine-tune, or swap a model. A document written once and filed away is wrong within a quarter. The instructions have to be generated from the system, not typed out beside it.
The output transparency requirement cannot be met with words at all. The Act says the system must be designed so a deployer can interpret its output. That is a user interface and an API contract, not a manual. If your system returns a single number with no confidence, no provenance, and no explanation, no instruction sheet can make that output interpretable.
The logging requirement is pure infrastructure. Article 13 references the records your system must keep, and Article 12 requires high-risk systems to automatically record events across their lifetime. You either built event logging into the system or you did not. You cannot describe logs you never captured.
Treat Article 13 as a compliance writing task and you will produce a document that fails an audit and a system that cannot be fixed in time. Treat it as engineering and you build something durable.
What Your Engineering Team Must Actually Build
Translate the article into a build list. Here is the work that EU AI Act Article 13 technical implementation actually demands, in the order that gives you the most return.
1. A Living System Card
Generate the instructions for use from your model registry, not your word processor. Every time a model version reaches production, the pipeline should emit a system card that pulls in the current accuracy metrics, the evaluation results by subgroup, the known limitations, the input data specifications, and the version history.
A compliant system card must include at minimum the following fields:
{
"provider": {
"name": "Acme AI Ltd.",
"registered_address": "...",
"contact_email": "ai-compliance@acme.com",
"eu_representative": "EU Representative GmbH, Berlin"
},
"system_name": "Acme Credit Risk Scorer v3.2",
"intended_purpose": "Automated creditworthiness assessment for retail lending decisions in EU member states",
"high_risk_category": "Annex III, Section 5(b): AI in essential private services — credit scoring",
"model_version": "3.2.1",
"release_date": "2026-05-15",
"performance": {
"overall_accuracy": 0.87,
"auc_roc": 0.91,
"subgroup_performance": {
"age_18_30": {"accuracy": 0.84, "false_positive_rate": 0.09},
"age_31_60": {"accuracy": 0.89, "false_positive_rate": 0.07},
"age_60_plus": {"accuracy": 0.82, "false_positive_rate": 0.11}
},
"robustness": {
"distribution_shift_test": "Pass — accuracy drop < 3% under covariate shift",
"adversarial_test": "Pass — FGSM attack accuracy degradation 4.2%"
},
"cybersecurity": "Penetration tested 2026-04-30, no critical vulnerabilities"
},
"known_risk_circumstances": [
"Performance degrades on applicants with fewer than 6 months of credit history",
"Not validated for non-EU regulatory contexts"
],
"input_data_specifications": {
"schema": "credit_application_v2.json",
"required_fields": ["income", "existing_debt", "employment_status", "credit_history_months"],
"training_dataset": "EU Retail Credit 2018-2024, n=2.3M",
"validation_dataset": "EU Retail Credit 2025, n=180K",
"test_dataset": "EU Retail Credit Q1 2026, n=55K"
},
"output_interpretation": "Score 0–1000. Scores below 400 indicate elevated credit risk. Confidence interval ±45 points at 95%. Feature attributions available via /explain endpoint.",
"human_oversight_controls": "All decisions below score 300 require human review before action. Override control available in the deployer dashboard. All human interventions logged.",
"compute_requirements": "GPU: A100 40GB or equivalent. Inference latency p99: 180ms.",
"expected_lifetime": "2026-05 to 2027-12; major retraining scheduled Q4 2026",
"logging_capabilities": "Inputs, outputs, confidence, model version, and human actions logged per Article 12. Log API: /logs/export. Retention: 5 years."
}
Store the system card alongside the model artifact. When the model changes, the document changes with it. This is the single highest-value thing you can build, because it turns a recurring manual chore into an automated output.
2. Output Interpretability Built into the Product Surface
A deployer must be able to read an output and judge whether to trust it. Give every high-risk output three things.
A confidence or uncertainty signal, so the user knows how sure the system is. For classification systems, this is a calibrated probability. For regression outputs, a confidence interval. Do not suppress this signal to make the UI cleaner — removing it is what the regulator will flag.
A provenance trail, so the user can see what data or sources drove the result. For RAG-based systems, this means displaying the retrieved sources and their relevance scores alongside the generated output. For non-RAG systems, it means feature attribution — SHAP values for tree-based models, LIME for black-box models, integrated gradients for neural networks. The explanation does not have to be mathematically precise at the surface level; it has to be legible enough for a human reviewer to understand why the system produced the output.
An explanation appropriate to the decision — a plain-language rationale the deployer can read. “Application declined: debt-to-income ratio (0.67) exceeds threshold; credit history length (4 months) is below the 12-month minimum” is a legible explanation. “Score: 312” is not.
These features belong in the interface and the API, designed in from the first sprint. For a fuller view of the observability infrastructure that supports interpretable outputs, our LLM integration enterprise guide covers the production telemetry that maps cleanly onto these requirements.
3. Automatic Event Logging
Article 12 requires high-risk systems to record events over their lifetime. Article 13 requires you to tell deployers how to use those logs. Here are the exact fields your event log must capture per prediction or decision:
| Field | Type | Description |
|---|---|---|
event_id |
UUID | Unique identifier for this logged event |
timestamp |
ISO 8601 | UTC timestamp of the prediction/decision |
session_id |
String | Groups related events within a user session |
user_id |
Hashed | Pseudonymised identifier of the human operator |
input_hash |
SHA-256 | Tamper-evident hash of the input data |
output_hash |
SHA-256 | Tamper-evident hash of the raw model output |
model_version |
SemVer | Exact version of the model that produced the output |
confidence_score |
Float 0–1 | Calibrated confidence of the output |
human_action |
Enum | ACCEPTED / OVERRIDDEN / ESCALATED / NO_ACTION |
override_reason |
String | Free text if human_action is OVERRIDDEN |
ground_truth |
Optional | Actual outcome, populated retrospectively where available |
latency_ms |
Integer | End-to-end inference latency |
Store logs in a tamper-evident store — append-only object storage with cryptographic integrity checks, or a dedicated audit log service. Define a retention period — the regulation does not specify one, but five years is defensible and aligns with common financial services record-keeping requirements. Expose a log export API so deployers can pull their own records.
4. Human Oversight Controls
Article 14 requires meaningful human oversight of high-risk systems. Article 13 requires you to document the technical features that support it. “Meaningful” is the operative word — oversight that exists only in a policy document does not count.
Your implementation must give the human reviewer three capabilities that Article 14 names explicitly:
The ability to understand what the system is doing and why it is producing a given output. This is satisfied by the interpretability features in build item 2 above — confidence signals, provenance, and plain-language explanation.
The ability to disregard the system’s output. This means a visible, accessible control in the deployer interface that lets the reviewer reject the system’s recommendation without that rejection being treated as an error or exception that triggers escalation. Build the control; make it the default path, not a buried option.
The ability to intervene or override and have that intervention recorded. Every override must be logged — who overrode, when, what the system said, what the human decided, and why. Without this audit trail, your oversight controls cannot be demonstrated to a regulator.
5. An Evaluation Harness That Backs Your Claims
The instructions for use must state the accuracy, robustness, and cybersecurity levels your system was tested against. That means you need a real evaluation harness, run on every release, that produces those numbers and stores them in the model registry.
Your harness must cover three test categories:
Accuracy — overall task performance on a held-out test set, plus disaggregated results by the subgroups relevant to your use case. For a credit scoring model, that means age bands, geographic region, and employment category. For a medical diagnostic system, it means age, sex, and clinical subgroup.
Robustness — performance under distribution shift. Run tests that simulate the data the system will encounter at the boundaries of its intended use: out-of-distribution inputs, missing fields, edge-case values. Measure accuracy degradation. The regulation’s threshold for acceptable degradation is not yet specified in harmonised standards, but building a benchmark now gives you a defensible baseline.
Cybersecurity — adversarial robustness. Run at minimum a Fast Gradient Sign Method (FGSM) attack and a model-inversion probe. For systems exposed via API, run basic prompt injection tests. Record the results. Add drift detection so you know when production performance diverges from the tested baseline — a system that was accurate at release but has drifted significantly is a compliance liability even if the system card is otherwise complete.
6. Input and Data Documentation in the Pipeline
The Act asks for specifications of the input data and the training, validation, and testing sets. This is not a one-time writeup — record the schema, expected value ranges, sources, and validation rules as part of the system at the point where the data pipeline and the model are coupled. Use dataset cards stored alongside the model artifacts in the registry. When the model is retrained on new data, the dataset card updates. The system card inherits the current dataset card automatically.
What Regulators Will Check During an Article 13 Audit
Knowing what an enforcement body will actually request changes how you build. EU AI Act enforcement will be handled by national market surveillance authorities in each member state, coordinating with the newly established European AI Office for cross-border and systemic cases. Based on the enforcement frameworks for GDPR — the most analogous regulation in scope and structure — here is what an Article 13 audit is likely to look like in practice.
The Evidence Package Auditors Will Request
Expect regulators to ask for: the current version of the instructions for use and the version history showing how it has changed over time; the evaluation reports that back the accuracy and robustness claims in the system card; the event logs for a specified period, demonstrating both what was captured and that the logs are tamper-evident; evidence that human oversight controls were actually used — not just that they exist, but that overrides were logged and that no period shows suspiciously uniform acceptance of system outputs; and documentation of the risk register, including how identified risks were mitigated or accepted.
Structuring Your Compliance Documentation Package
Do not produce these documents manually at audit time. Build your compliance documentation package as a continuous output of your engineering systems. The system card should be versioned and stored in a document management system with access controls. Evaluation reports should be linked to specific model versions in the registry. Logs should be exportable by date range and accessible to your legal team without engineering involvement.
The difference between an audit-ready organisation and one that scrambles is almost entirely a matter of whether the documentation pipeline is automated or manual. Manual processes produce stale documents and create gaps during handoffs. Automated pipelines produce current documentation as a side effect of normal engineering work.
Common Gaps That Cause Audit Failures
In our work with enterprises building regulated AI systems, the gaps most likely to cause audit findings are:
Subgroup evaluation missing or thin — teams test overall accuracy but do not have the labelled test data needed to produce disaggregated performance figures by the relevant subgroups. Correcting this requires reconstructing test sets, which is expensive to do under time pressure.
Override controls exist but overrides are not logged — the UI has a button, but the backend does not capture who pressed it, when, or why. The audit trail is empty.
System card describes the first version of the model, not the current one — the document was written at launch and never updated. The model has been retrained twice since.
Logs are captured but not accessible — event logs are written to a storage bucket, but there is no export API and no tooling for the legal or compliance team to query them without engineering support.
The Difference Between “We Have Documentation” and “Our System Is Transparent”
An audit-proof Article 13 posture is not about producing a thick document. It is about a system that, by construction, generates evidence of its own transparency. A deployer who receives the instructions for use should be able to verify the accuracy claims by looking at a real evaluation report. A regulator who requests logs should receive a structured, queryable dataset, not a raw file dump. A human reviewer who acts on the system’s output should leave a trail. If your documentation only exists in documents — if none of it is generated from or verifiable against the system itself — it will not hold up.
A Practical Build Plan for the Next Eighteen Months
You have until December 2027. Spend the time in three phases.
Phase 1: Inventory and Gap Assessment (Now — Q3 2026)
List every AI system that is likely to fall under Annex III. Run the self-assessment checklist from the earlier section. Map each system against the six build items above: living system card, output interpretability, event logging, human oversight controls, evaluation harness, and data documentation. For each system, mark what exists, what is partial, and what is missing entirely. Most teams find that subgroup evaluation and event logging are the biggest gaps. The inventory tells you where to spend first.
Phase 2: Build Shared Foundations (Q4 2026 — Q2 2027)
The system card pipeline, the event logging store, and the evaluation harness are common infrastructure that every high-risk system in your portfolio can reuse. Build them once as a platform capability, not once per product. The per-system work then becomes: populate the system card with the correct values for this model, wire the event logging schema to this system’s inputs and outputs, run the evaluation harness against this system’s test set. Investing in the platform now reduces the per-system integration cost dramatically. Our agentic AI governance guide covers how similar shared compliance infrastructure is structured for agentic systems — the architecture principles carry across to Article 13 work.
Phase 3: Integrate, Test, and Rehearse (Q3 2027 — November 2027)
Wire each high-risk system into the shared foundations and run a mock audit. Give a deployer the generated system card and the log export API, and check whether they can interpret an output without calling your engineering team. Give your legal team the evaluation reports and check whether they can answer a regulator’s question about subgroup performance without digging through raw data. The systems that pass are ready. The ones that fail tell you what to fix while you still have five months.
APAC Enterprises Selling into the EU: What You Need to Know
For enterprises headquartered in Singapore, Hong Kong, or elsewhere in Asia-Pacific, the EU AI Act’s extraterritorial scope is not a minor footnote. It is a significant operational obligation for any company with EU customers or EU data subjects affected by its AI systems.
The Extraterritorial Reach: Jurisdiction Follows the Output
The Act’s scope is clear: it applies to AI systems placed on the market or put into service in the EU, and to systems whose outputs are used in the EU, regardless of where the provider is established. A Singapore-based HR technology firm whose AI screening tool processes applications from EU-based job candidates at EU subsidiaries of its customers is within scope. A Hong Kong insurer whose underwriting model assesses EU-resident policyholders is within scope. The place of incorporation does not create an exemption.
Providers established outside the EU that deploy high-risk AI systems falling under the regulation must designate an authorised representative established in the EU. That representative is the point of contact for market surveillance authorities and is jointly liable for compliance.
Practical Steps for APAC Enterprises with EU Customers
The immediate actions for APAC-based organisations to take before the December 2027 deadline:
Map which of your AI systems produce outputs affecting EU residents. Run the Annex III checklist against each one. Confirm whether any of those systems are high-risk.
If high-risk systems are identified, appoint an EU representative and begin the Article 13 build program. Do not wait for the standards bodies to finalise harmonised standards before starting — the build items above are clear from the Act’s text.
Register your high-risk AI systems in the EU database for high-risk AI systems when it becomes operational (the Commission is expected to launch the database in 2026). Registration is a compliance requirement, not optional.
Singapore’s Model AI Governance Framework and the EU AI Act: Where They Align
Singapore’s Model AI Governance Framework (MAS’s FEAT principles and IMDA’s Model AI Governance Framework, updated in 2024) and the EU AI Act share a common architecture: transparency, accountability, and human oversight as foundational principles. The frameworks align on the need to document AI system capabilities and limitations, to provide interpretable outputs, and to maintain meaningful human oversight of consequential decisions.
Where they diverge is in enforcement mechanism and specificity. The EU AI Act is binding regulation with penalties of up to €35 million or 7% of global annual turnover for providers of prohibited AI practices, and up to €15 million or 3% for violations of obligations including Article 13. Singapore’s framework is still primarily voluntary, though the Personal Data Protection Commission (PDPC) has enforcement powers where AI use intersects with personal data under PDPA.
The practical implication for APAC enterprises: building to EU AI Act Article 13 standards means building to a level that exceeds current Singapore regulatory requirements. An Article 13-compliant system card is also a strong response to MAS or IMDA requests for AI governance documentation. Building once to EU standard and documenting the alignment to Singapore’s framework is more efficient than maintaining two separate compliance programs.
What Comes Next
Two shifts are worth watching over the next eighteen months.
The standards bodies are filling in the detail. The Act sets the obligation. The harmonised standards from CEN-CENELEC will define how to meet it — turning the loose phrase “sufficiently transparent” into specific, testable requirements for log content, evaluation methodology, and output explanation format. As those standards mature, the build items above will acquire more precision. Build with margin now so a stricter standard does not force a rebuild.
The tooling is catching up. Model registries, evaluation platforms, and observability vendors are shipping Article 13 features as first-class capabilities. By the time December 2027 arrives, mature tools will exist that automate large parts of the system card pipeline and the evaluation harness. Adopting a mature tool will be cheaper than building everything from scratch, and the build list does not change regardless — only who writes the code does.
The companies that handle EU AI Act Article 13 technical implementation well will treat it as product and platform engineering, not a compliance document due at the end. The delay to December 2027 does not change that work. It only decides whether you build calmly or in a panic.
How Sthambh Builds Article 13-Ready AI Systems
Article 13 compliance is an engineering problem that requires someone who has solved it before. Most of the teams we work with arrive at the same point: they understand the regulation, they have a list of high-risk systems, and they need to close the gap between where they are and where the law requires them to be — with a deadline that is closer than it looks.
Sthambh builds the compliance-aware platform layer that makes Article 13 tractable: the automated system card pipeline connected to your model registry, the event logging store with the schema and API your legal team can actually use, the evaluation harness producing disaggregated subgroup results at every release, and the human oversight controls built into the product surface rather than bolted onto it. Our agentic AI engineering work is structured around exactly this kind of foundational compliance infrastructure, where transparency and human oversight are part of the system architecture from the first sprint. We have done this for enterprises in financial services, healthcare, and professional services across Asia-Pacific and the UK.
If your organisation is based in Singapore or Hong Kong and has EU customers, or if you are a UK or EU enterprise building toward the December 2027 deadline, the inventory and gap assessment is the right place to start. We will tell you which of your systems are in scope, where your biggest gaps are, and what the build sequence should look like given your team size and the December 2027 timeline.
Book a 45-minute Article 13 readiness call with Sthambh’s team. We will review your AI system portfolio, identify the high-risk systems, and give you a concrete build plan before you leave.
FAQs
Q. What does EU AI Act Article 13 require for high-risk AI systems?
A. Article 13 requires two things: the system itself must be designed so its operation is transparent enough for a deployer to interpret the output correctly, and the system must ship with a comprehensive set of instructions for use. Those instructions must cover provider identity, intended purpose, accuracy and robustness metrics, known risk circumstances, subgroup performance, input data specifications, output interpretation guidance, human oversight features, compute requirements, expected lifetime, and logging capabilities. Every item on that list is an engineering artifact, not a document that can be written separately from the system.
Q. Has the EU AI Act Article 13 deadline been delayed?
A. Yes, provisionally. The Digital Omnibus agreement of 7 May 2026 pushed the Annex III high-risk obligations from 2 August 2026 to 2 December 2027. Annex I product-embedded systems moved to 2 August 2028. The agreement still requires formal adoption, expected over summer 2026. The dates could shift at the margins; the direction will not. Critically, the requirements themselves did not change — only the deadline moved.
Q. Does the EU AI Act apply to companies based in Singapore or Hong Kong?
A. Yes, if their AI systems produce outputs that affect people in the EU. The Act’s scope is determined by where the output is used, not where the provider is based. A Singapore HR-tech firm whose AI screening tool processes EU-based job applicants, or a Hong Kong insurer whose underwriting model assesses EU-resident policyholders, falls within scope. Providers outside the EU must designate an authorised EU representative and register high-risk systems in the EU AI database.
Q. What is a “living system card” and how do I generate one for Article 13 compliance?
A. A living system card is a machine-generated document that describes a specific version of your AI system — its purpose, performance metrics, known limitations, input data specifications, and logging capabilities — and updates automatically every time the model version changes. The key word is “living”: a system card written once and stored in a document folder is out of date within a quarter. Build the system card as a pipeline output from your model registry, so every release automatically emits a current, version-controlled system card that reflects the model’s actual tested performance. The JSON schema in this article shows the minimum fields required for an Article 13-compliant system card.
Q. What is the difference between Article 13 transparency and Article 14 human oversight?
A. Article 13 governs what information a provider must give to deployers — the instructions for use, the interpretability features, and the logging capabilities. Article 14 governs what deployers must be able to do with that information: understand the system’s output, disregard it, and intervene or override it. The two articles are complementary. Article 13 says the system must expose the information and controls. Article 14 says deployers must use those controls to maintain meaningful human oversight. An engineering team building Article 13 compliance will implement most of the technical infrastructure that Article 14 also demands — interpretable outputs, visible override controls, and logged interventions.
Q. How do I know if my AI system falls under the EU AI Act’s high-risk category?
A. Run the Annex III checklist: does the system influence decisions about education access, employment, credit, essential services, law enforcement, migration, justice, or democratic processes? Does it perform remote biometric identification in publicly accessible spaces? Is it a safety component of critical infrastructure? If yes to any of these, treat it as high-risk and begin an Article 13 compliance assessment. When in doubt, start with the inventory — understand what your systems do and who they affect — before deciding whether a formal legal opinion is needed. The cost of mistakenly treating a non-high-risk system as high-risk is low. The cost of the reverse is not.
Nikhil Khandelwal
Co-founder & CTO, Sthambh
