EU AI Act CIO/CTO Playbook: Technical Obligations You Must Build For

# The AI Act Is an Engineering Problem, Not Just a Legal One

Every eu ai act cio cto conversation eventually lands in the same place: compliance counsel hands the technical team a PDF, and someone has to turn legal text into infrastructure. That someone is you. The good news is the obligations are specific enough to plan around. The hard part is that most SME tech stacks were not designed with AI governance in mind, so the work is real.

This playbook covers what Article 12, Article 26, and Article 9 actually require you to build, how to evaluate vendor AI systems before you deploy them, and what your monitoring architecture needs to look like. No vague frameworks. Concrete engineering implications.

---

# Step One: Build Your AI System Inventory

You cannot govern what you cannot see. Before any tooling decision, you need a structured inventory of every AI system your organisation deploys. Under Article 26 of the EU AI Act, deployers carry specific obligations that attach to individual systems, not to AI in general. Without an inventory, you have no way to know which obligations apply where.

Your inventory should capture at minimum:

• System name and vendor
• Use case and business process it touches (e.g., CV screening in recruitment, credit scoring in sales)
• Risk classification (prohibited, high-risk, limited risk, minimal risk)
• Data inputs and outputs
• Who in the organisation is the designated human overseer
• Where logs are stored and for how long

Risk classification is where most SME tech leaders get stuck. The high-risk categories are defined in Annex III of the AI Act. They include AI systems used in recruitment and HR management, access to education, essential private services, and critical infrastructure. If your company uses an AI tool for any of these, it is a high-risk system and the full compliance regime applies.

Keep the inventory in a living document. It is not a one-time audit. New SaaS tools get added quarterly. An employee starts using an AI-powered performance management platform without central procurement. A vendor quietly adds an AI feature to a product you already use. Your inventory process needs to catch all of this.

---

# Article 12: What Logging Infrastructure You Must Have

Article 12 is the most direct technical obligation in the Act for CIOs and CTOs. It requires high-risk AI systems to automatically log events throughout their operation, with sufficient granularity to enable post-hoc accountability.

Specifically, logs must enable identification of:

• The period of each use of the system
• The reference database against which input data was checked
• Input data that led to a given output or decision
• The identity of the natural persons involved in verification of results

For most SMEs, this means your logging architecture needs to change. Relying on a vendor's own audit trail is often insufficient because you need logs that you control, that cannot be retroactively altered by the vendor, and that can be produced on request to a market surveillance authority.

Practically, this means:

1. Request log export access from every high-risk AI vendor. If a vendor cannot give you tamper-evident log exports in a structured format, that is a procurement red flag.
2. Store logs in your own environment. Whether that is your SIEM, a dedicated logging service, or object storage, the logs must live somewhere you own.
3. Set retention to match the Act's expectations. The Act does not specify a single retention period universally, but the Commission guidance on high-risk systems and sector-specific requirements typically point to a minimum of three years for high-risk system logs. Align with your GDPR data minimisation obligations simultaneously.
4. Tag log entries with the human decision-maker. Where a human reviews AI output and makes a final call, that reviewer's identity must be traceable. This often means building a thin wrapper or confirmation screen in your internal tooling that writes a structured log entry at decision time.

---

# Article 9: Risk Management as a Technical Discipline

Article 9 requires providers of high-risk AI systems to establish a risk management system. For deployers, the obligation maps to Article 26, which requires you to implement the provider's risk management instructions and to monitor for risks that emerge in your specific operating context.

In engineering terms, this means you need a monitoring pipeline that watches for:

• Accuracy drift: Is the model's performance degrading over time compared to a baseline?
• Distributional shift: Are the inputs your users are sending different from what the model was trained on?
• Adverse outcome rates: Are certain demographic groups receiving systematically different outputs? This is particularly critical in HR and financial services use cases.
• Human override rates: If users are overriding or ignoring AI recommendations at a high rate, that is a signal the system is not performing as intended.

For SMEs, a full MLOps platform is often out of scope. You do not need Kubernetes and a bespoke feature store. You do need a scheduled job that queries your logs weekly, computes simple statistics, and raises an alert when thresholds are breached. Start simple. The obligation is to monitor, not to build a perfect ML observability stack on day one.

---

# Vendor Evaluation: What to Demand Before You Sign

Article 26 makes deployers responsible for using AI systems in accordance with the instructions of use provided by the provider. That means the provider must give you instructions of use. If they do not, or if those instructions are vague, you carry risk you cannot manage.

Before signing any contract for an AI system that touches a high-risk use case, require the vendor to provide:

• A completed EU Declaration of Conformity (mandatory for high-risk AI providers under the Act)
• A copy of technical documentation summarising training data sources, performance metrics, and known limitations
• Logging and audit trail capabilities in writing, not just in a sales deck
• Incident notification procedures: if the system fails or behaves unexpectedly, how and how quickly will they tell you?
• Post-market monitoring reports: what data are they collecting about the system's real-world performance?

If a vendor cannot answer these questions before contract signature, that tells you exactly what their AI governance maturity looks like. Build vendor AI governance into your standard procurement checklist alongside your existing security and GDPR due diligence.

---

# Deadlines Your Engineering Roadmap Must Reflect

The Act entered into force on 1 August 2024. The key dates for deployers of high-risk systems are:

• February 2025: Prohibited AI practices become enforceable
• August 2026: Full obligations for high-risk AI systems under Annex III apply
• August 2027: Obligations extend to high-risk AI systems embedded in regulated products

August 2026 is the hard deadline for most SME deployers. That is less than 18 months away from the time of writing. A realistic engineering roadmap needs to start with the inventory this quarter, move to logging infrastructure in the next, and have monitoring tooling validated before end of year.

Penalties are real. Under Article 99, infringements by deployers can reach €15 million or 3% of global annual turnover, whichever is higher. For an SME with €10 million turnover, that is €300,000. Build the compliance infrastructure now; it is far cheaper than the alternative.

---

# Human Oversight Is a Feature, Not a Process

One final engineering principle. Article 26 requires deployers to implement human oversight measures. Too often, compliance teams interpret this as a policy document. It is an engineering requirement. Your interfaces must make it possible for a human reviewer to understand, question, and override AI outputs.

That means:

• AI outputs must display confidence scores or uncertainty indicators where technically feasible
• Reviewers must be able to access the input data that generated a recommendation
• Override actions must trigger a structured log entry
• Systems must not present AI outputs as final decisions without explicit human confirmation

Build these patterns into your design system now. They will serve you across every AI tool your organisation deploys.

---

If you want a clear view of where your organisation stands today, the free 2-minute compliance check at comply.khairos.ai maps your current AI use against the Act's obligations and tells you which gaps to prioritise first.