Architect

Regulatory obligations impose specific architectural constraints. Addressing these retroactively is significantly more expensive than incorporating them during design. The system architecture should distinguish three functional layers: the inference pipeline, the monitoring pipeline, and the governance pipeline — separating concerns so governance controls do not create performance bottlenecks.

• Human oversight integration (Art. 14): human-in-the-loop for high-consequence decisions, human-on-the-loop for moderate-volume monitoring, human-in-command for strategic control of high-volume systems
• Explainability architecture (Art. 13): model-agnostic explanation services (SHAP, LIME), feature attribution pipelines, counterfactual generators, and natural language explanation layers
• Fairness and non-discrimination controls (Art. 10): bias detection at training and inference time, protected characteristic proxy analysis, fairness metric engines supporting demographic parity, equalised odds, and calibration
• Robustness and cybersecurity (Art. 15): adversarial input detection, model integrity verification via cryptographic hashing, secure model serving, input validation, and defence-in-depth deployment
• Multi-tenancy governance: tenant-aware logging, monitoring, access control, and data isolation preventing cross-tenant data leakage

Data governance is the area of greatest regulatory overlap in AI governance. The EU AI Act, GDPR, sector-specific regulations, and management system standards all impose data-related requirements across the entire data lifecycle — from collection through deletion.

• Collection: lawful basis under GDPR, consent management, data licensing, provenance documentation, Art. 10(2) training data relevance and representativeness
• Labelling: quality assurance, inter-annotator agreement measurement, annotator qualifications documentation
• Training: data split documentation, stratification strategy, augmentation methods, synthetic data provenance
• Inference: input data validation, schema enforcement, out-of-distribution handling, real-time quality checks
• Retention and deletion: aligned to regulatory minimums (EU AI Act: 6 months minimum for logs) and maximums (GDPR storage limitation), with automated deletion workflows
• Third-party data: vendor due diligence, contractual data quality warranties, ongoing quality monitoring

Governance must be integrated into ML pipelines so compliance is enforced automatically as part of normal operations rather than assessed manually after the fact. Everything contributing to a model's behaviour must be version-controlled: code, configurations, hyperparameters, data manifests, evaluation scripts, and deployment configurations.

• Training pipeline: complete records per run — data version, architecture, hyperparameters, seeds, compute, metrics — stored immutably and linked to the resulting model version
• Validation and testing: performance benchmarking against thresholds, bias testing across protected characteristics, robustness testing under adversarial inputs and distribution shift, security testing against extraction and poisoning
• Deployment pipeline: staged rollout (canary, A/B, progressive), tested rollback procedures, approval gates requiring engineering lead, governance lead, and human oversight sign-off
• Continuous training: governed retraining with documented triggers, data governance checks, full validation pipeline, regression testing, and retraining approval gate
• GPAI model integration: upstream model version tracking, re-evaluation on version changes, model card review, downstream obligation inheritance documentation

Multiple frameworks mandate technical documentation. The EU AI Act's Annex IV requirements are the most prescriptive, but GDPR Records of Processing Activities, DPIAs, NIS2 security documentation, and ISO management system documentation each impose their own requirements. Maintaining separate packages is unsustainable — a unified documentation architecture structures information once and presents framework-specific views.

• Annex IV: general description, design specifications, data governance measures, validation and testing procedures, monitoring capabilities, risk management system, human oversight measures, accuracy and robustness specifications
• Annex V QMS: regulatory strategy, design procedures, testing procedures, data management, risk management, post-market monitoring, incident reporting, record-keeping, accountability framework
• GDPR: Records of Processing Activities (Art. 30), DPIA reports (Art. 35), Legitimate Interest Assessments
• Cross-framework consolidation: single technical description serves Annex IV, DPIA processing description, and ISO 42001 system characterisation — single risk assessment satisfies Art. 9, DPIA, NIS2, and ISO requirements

Technical documentation is only valuable if it is current, accessible, and trustworthy. Static documentation produced at launch and left unmaintained becomes a compliance liability. Living documentation must be updated whenever the AI system changes, integrated with ML pipelines and change management to automate update triggers.

• Documentation-as-code: version-controlled alongside system code, change tracking with authorship and rationale, review workflows via pull requests, diffing and rollback for audit
• Automated generation: architecture diagrams from infrastructure-as-code, data flow maps from pipeline configurations, metrics from evaluation outputs, training data statistics computed and inserted automatically
• Access control: role-based views — regulators see full Annex IV, deployers see instructions for use, auditors see complete evidence trail, affected persons see appropriate transparency disclosures
• Retention: Annex IV documentation kept for 10 years after market placement, GDPR documentation for the processing period, ISO records per the organisation's retention policy