From AI pilots to compliance with the AI Act: a pragmatic approach to AI governance

The conversation around artificial intelligence has changed radically over the past two years.
Many organisations began by experimenting with conversational assistants, co-pilots, predictive models or intelligent agents. Some achieved promising results. Others quickly discovered that deploying AI in production is far more complex than running a proof of concept.
Today, the questions are no longer purely technological:
- What AI systems are actually in use?
- Who is responsible for each of them?
- What data do they use?
- What risks do they pose?
- How do we demonstrate that they operate safely, responsibly and in compliance with the regulations?
And as these questions become increasingly important, the regulatory landscape is evolving. Against this backdrop, there is a misconception in the market:
To meet these requirements, it is necessary to undertake complex, lengthy and costly projects.
The reality is quite different.
You don't need to go all out right from the start
Most organisations do not need to implement a Artificial Intelligence Management System (AIMS) fully operational from day one.
Some simply need:
- Take stock of your AI systems.
- Identify those responsible.
- List models.
- Document the data used.
- Assess basic risks.
- Keep records.
Others are already equipped to tackle more advanced scenarios relating to regulatory compliance, comprehensive risk management, impact assessments and audits.
That is why, at Anjana Data, we have designed our SGIA with a forward-thinking approach.
The platform allows you to start with the basics and gradually move towards advanced models of governance, compliance and auditing without having to switch tools, redo work that has already been done, or introduce new technologies every time the organisation’s level of maturity increases.
Technology supports the organisation as it evolves, rather than the other way round. This reduces the learning curve, makes change management easier and significantly speeds up time-to-value.
Once AI goes live, government involvement is no longer optional
Most organisations can manage one or two AI use cases in a relatively informal manner.
The problem arises when AI starts to scale up. New models, new teams, new suppliers, new data sources and new responsibilities emerge.
Organisations deploying artificial intelligence in Europe are no longer wondering whether they will have to comply with the AI Act 2024/1689, the ISO/IEC 42001 or the transparency requirements for GPAI models. The question is: when will the first inspection take place, and how long will it take us to respond?.
And in this context, specific questions arise that need to be answered reliably and promptly:
- Which models are using personal data?
- Which systems might be considered high-risk?
- Who passed a particular assessment?
- What mitigation measures are in place?
- What evidence can we provide during an audit?
- How do we demonstrate compliance with the AI Act?
Most people admit, in private, that the information needed to answer these questions is currently scattered across spreadsheets, PDFs on SharePoint and the MLOps team’s collective memory. And that’s unmanageable.
That is why the only viable option is to turn AI governance into a structured and operational process.
From the AI Act to an operational platform
At Anjana Data, we have applied artificial intelligence to the same process that we previously developed for data governance initiatives, corporate catalogues, data quality, data lineage, open data and data hubs.
Translate regulatory frameworks, standards and best practices into actual platform configurations without the need for development work.
The result is a Artificial Intelligence Management System (AIMS) deployable on the Anjana Data Platform, aligned with:
- AI Act (EU Regulation 2024/1689).
- ISO/IEC 42001.
- ISO/IEC 23894.
- ISO/IEC 42005.
- ISO/IEC 22989.
- UNE 0077.
- UNE 0078.
- UNE 0079.
This is neither a concept model nor a future proposal. It is an actual configuration that we deploy in production environments.
A model designed to grow alongside the organisation
The great advantage of a metadata- and configuration-based approach is that it allows for seamless evolution.
An organisation can start by managing only:
- AI systems.
- Models.
- Use cases.
- Those responsible.
- Basic risks.
And subsequently incorporate more advanced capabilities such as:
- Impact assessments.
- Comprehensive risk management.
- Technical documentation.
- Compliance with the AI Act.
- GPAI model management.
- Operational observability.
- Ongoing audit.
All of this on the same platform, with the same user experience and ensuring full traceability of the information.

The core of the SGIA: governance, risk and traceability
The configuration includes:
- More than 18 specialist roles for governance, compliance, risk and operations, organised into three sections:
- Corporate governance: CDO, DPO, CISO, Legal IP Officer
- Data governance and data quality in accordance with UNE 0077/0078/0079: Data Owner, Data Steward, Data Quality Director/Analyst, Data Architect
- SGIA-specific operation: AI System Owner, AI Delegate, AI Human Oversight, AI Compliance Officer, AI Risk Owner, AI Auditor, AI Incident Manager, GPAI Model Owner, Model Validator
- Each role with surgical authorisations and segregation of duties in accordance with ISO 42001 — the auditor does not alter what they are auditing; the validator does not develop the model they are validating.
- More than 18 specialist roles for governance, compliance, risk and operations, organised into three sections:

- More than 25 subtypes of entities which cover:
- The crux of the AI Act: `AI_SYSTEM`, `AI_MODEL`, `AI_USE_CASE`, `SUMMARY_OF_GPAI_TRAINING_CONTENT`, `AI_PROVIDER`.
- Risk and impact management: `RISK_ASSESSMENT_IA`, `IMPACT_ASSESSMENT_IA`, `CONTROL_MEASURE`, `CONTROL_EVIDENCE`.
- The SGIA process: `TECHNICAL_DOCUMENTATION_IA`, `COMPLIANCE_FILE_IA`, `MONITORING_PLAN_IA`, `INCIDENT_IA`, `NON-COMPLIANCE_SGIA`, `CORRECTIVE_ACTION_SGIA`.
- Data governance according to UNE: `DATA_POLICY`, `DATA_INITIATIVE`, `DATA_QUALITY_REQUIREMENT`, `DATA_QUALITY_MEASUREMENT`.
- The GDPR: `PROCESSING`, `DPIA_ASSESSMENT`, `SECURITY_BREACH`.
- More than 30 subtypes of relationships which enable end-to-end traceability:
- System governance chain: system ↔ use case ↔ model ↔ documentation ↔ compliance file ↔ supplier
- Risk chain: system → risk → measure → evidence
- Data → model → production pipeline: model ↔ training, validation and production datasets
- GDPR chain: processing ↔ DPIA ↔ FRIA ↔ breach
- More than 25 subtypes of entities which cover:

- Preloaded controlled vocabularies aligned with the standard:
- Risk classification under Article 6: unacceptable, high, limited, minimal
- Domains listed in Annex III
- ISO 23894 risk categories
- Types of ISO 22989 standard
- Training data formats under Article 53
- Special categories under Article 9 of the GDPR
- Controls in Annex A of ISO 42001
- Menus from templates configured, validations mandatory and workflows for approval.
The aim is not to produce more documentation. It is to turn the information needed to govern AI into a living, manageable asset.
Designed for high-risk systems and GPAI models
The SGIA covers the two main categories of obligations introduced by the AI Act from August 2026:
- High-risk systems (Articles 6–15, Annex III): Each `SISTEMA_IA` has five template menus — Identification, Technical, Compliance, SGIA Management and Operational Observability — with mandatory fields that prevent a system from being registered without a risk classification, without the appointment of a human supervisor as required by Article 14, without an assessment of exceptions under Article 6(3) and without a scope record under Article 2 (including extraterritoriality under Article 2(1)(c) where the output is used in the EU).
- Technical documentation for Annex IV: The `DOCUMENTACION_TECNICA_IA` entity provides a structured mapping to the points in Annex IV and the sections of ISO 42001. It allows you to answer the question «Which document covers point 3 of Annex IV?» in a matter of seconds, without having to open a single PDF.
- GPAI models (Articles 53–55): The `RESUMEN_CONTENIDO_ENTRENAMIENTO_GPAI` entity models the data types (text, images, audio, video, code, synthetic data), the corpus size within the ranges that the AI Office will require to be published, the aggregated sources by type, the policy on respecting TDM opt-outs in accordance with Directive 2019/790, and the specific detection mechanisms (robots.txt parsing, TDM headers, whitelists/blacklists, individual agreements). The «GPAI Model» flag in `MODELO_IA` automatically triggers the creation of the linked entity.
- Fundamental Rights Impact Assessment (FRIA): The FRIA is not a separate entity: it is precisely what is documented in `EVALUACION_IMPACTO_IA`, in accordance with Article 27 of the AI Act and the ISO 42005 methodology. It includes vulnerable groups, impacts by fundamental right and a binding conclusion (Acceptable / Requires mitigation / Unacceptable).
Post-marketing surveillance (Art. 72) and reporting of incidents (Art. 73): The `PLAN_MONITORIZACION_IA` and `INCIDENTE_IA` entities complete the operational lifecycle with metrics, thresholds, frequencies and deadlines for reporting to the regulator.

Ready to deploy: no code, no friction
Like all Anjana Data configurations designed to accelerate the implementation of use cases on the Anjana Data Platform, the SGIA is delivered out of the box:
- Automated deployment in record time on any instance of the Anjana Data Platform.
- No development is required. The configuration is applied via a REST API, and the client can customise attributes, vocabularies and workflows without compromising compliance with the standard.
- Built-in validations: critical fields (risk classification, scope under Article 2, FRIA conclusion) are mandatory. A system cannot be set to «Active» status without the associated regulatory documentation.
- Templates and sections organised for ease of use: each menu groups attributes by category of obligations, so that the end-user—who is not necessarily an expert in the AI Act—knows what to fill in and why.
End-to-end traceability: from use case to data
This is the key feature of Anjana Data’s SGIA. The AI Act requires providers and deployers to maintain traceability use → system → model → data. Most organisations keep it to hand, in an Excel spreadsheet that is never up to date.
In SGIA, that chain is navigable:
- One use case (`CASO_USO_IA`) records the scope of Annex III, the intended users and the preliminary assessment of the impact on fundamental rights. If the response is «High», the workflow blocks activation until the FRIA has been signed.
- The use case is linked to the AI system that runs it. The same neural network may be classified as low-risk when labelling spam and high-risk when deciding on a loan: the AI Act regulates the use case, not the model.
- The system adds one or more models (`MODEL_AI`), including its accuracy, robustness and cybersecurity metrics as required by Article 15, its classification in accordance with ISO 22989, and its GPAI flag where applicable.
- Each model connects to the datasets who trained it, validated it and feed it during production. When a data subject exercises their right to erasure under Article 17 of the GDPR, we can identify all the models that processed that data. When a bias appears in the output, we can trace back to the dataset that introduced it.
- The dataset has its own technical lineage — RAW → Silver → Gold — and its consumption pattern towards Power BI, where the reports are linked to KPIs and the KPIs with terms from the corporate glossary.
The result: a single platform where the question «Which personal data feeds which models, which systems run them, in which use cases, with which DPA signed by whom?» is answered with a few clicks, not with meetings.

Data governance, the GDPR and the AI Act in a single thread
The AI Act devotes an entire section—Section 10—to data quality for high-risk systems. If the data governance system resides in one tool and the AI governance system in another, this requirement necessitates a manual workaround that is never fully complete.
SGIA reuses the data governance and quality metamodel that Anjana Data already provides natively:
- UNE 0077: Policies, initiatives, designated responsibilities and data risks associated with the AI system.
- UNE 0078: Classification, lifecycle, architecture, data security and privacy (including the designation of special categories under Article 9 of the GDPR, which automatically triggers the obligation to carry out a DPIA under Article 35).
- UNE 0079 / ISO 25012: Quality assessment based on inherent and system-dependent characteristics, including an improvement plan and metrics.
- Data for AI: A specific section covering bias, representativeness, labelling and preparation. This is where the requirement in Article 10 to «document data quality to the extent possible» is put into practice.
- Native GDPR compliance: `PROCESSING` (RAT under Art. 30), `DPIA_ASSESSMENT` (Art. 35) and `SECURITY_BREACH` (Arts. 33–34), linked to the AI system via specific relationships (`DPIA_SYSTEM`, `SYSTEM_PROCESSING`, `DPIA_FRIA`).
The DPO issues their opinion on the DPIA; the AI Risk Owner signs off on the AI risk assessment; the Data Owner authorises the dataset; and the Legal IP Officer approves the GPAI summary. Three worlds, a single traceability chain.
Operational observability: from MLOps to governance
Each `SISTEMA_IA` and each `MODELO_IA` includes a menu of Operational observability with sections dedicated to performance, availability and SLOs, runtime quality, cost and consumption, model drift and technical traceability.
These attributes do not fill in by hand. They are synchronised via:
- Anjana Data REST API: documented endpoints, OAuth authentication, idempotent. Any MLOps platform can push metrics.
- Native plugins: Dynatrace, MLflow, Evidently, Datadog, Helicone, LangSmith, Langfuse, and the model registries of the leading cloud providers.
The idea: AI technical management layer ↔ AI governance layer. MLOps tools handle day-to-day operations; Anjana Data transforms those operations into metadata that is governable, auditable and reportable to regulators. This puts an end to the classic discrepancy between «what Datadog knows» and «what the compliance report says».
A modular solution, ready to grow
Anjana Data's SGIA is the configured base, not the ceiling:
- Sector-specific extensions. Banking, healthcare, the public sector, HR, critical infrastructure: each domain can add specific attributes without altering the base metamodel.
- Proprietary metadata. Organisations that already have risk taxonomies, internal controls or governance KPIs can incorporate these as additional attributes.
- Customisable governance workflows. Who approves what, under which SLA, with what notifications, and based on what evidence. Approval workflows are modelled within the platform.
- Integration with the rest of the Anjana ecosystem: DCAT-AP-ES open data catalogue, data product marketplace, corporate glossary, technical lineage, KPIs and governed reports. The SGIA inherits all of these.
The aim is not simply to comply. It is to govern.
Regulatory compliance is merely a consequence. The real aim is to have a comprehensive, reliable and auditable overview of how the organisation uses artificial intelligence.
Because the organisations that will derive the most value from AI will not necessarily be those with the most models. They will be those capable of managing, operating and scaling them with confidence.
Would you like to see it in action?
We have a 50–60-minute demo which covers the entire SGIA framework in relation to a real-world case: from the creation of a use case, its risk classification in accordance with Annex III, the technical documentation of Annex IV, the FRIA under Article 27, the risk assessment in accordance with ISO 23894 with its control measures and supporting evidence, the IA model with its metrics under Article 15, the GPAI summary under Article 53, the training datasets governed in accordance with UNE 0077/0078/0079, right through to the technical lineage to Power BI and the data access marketplace.
The demo is tailored to the audience—executive committee, CDO/CDAIO, DPO, technical buyer—and demonstrates exactly how to respond within minutes to the question that is bound to come up during the first audit: «Please provide us with the inventory of high-risk AI systems, including their classification, signed risk assessment and full technical documentation.»
You can do it now immediately, without the need for development, using a 100% solution that complies with the AI Act, ISO/IEC 42001 and the UNE data governance standards.
This isn’t just documentation. It’s a living management system.
