Registrul de Modele ML este Fundatia Conformitatii cu EU AI Act

Intrebarea Care Darama Auditurile de Conformitate

Iata o intrebare care iti va strica ziua: ce versiune exacta de model ruleaza in productie chiar acum?

Nu "cea mai recenta." Nu "cea pe care am antrenat-o luna trecuta." Versiunea exacta, cu snapshot-ul datelor de antrenare, hiperparametrii, metricile de evaluare si persoana care a aprobat-o pentru deployment.

Daca nu poti raspunde in mai putin de 60 de secunde, ai o problema de conformitate. Iar cu cerintele de documentatie tehnica din Anexa IV a EU AI Act aplicabile pentru sistemele AI cu risc ridicat, aceasta problema de conformitate are un termen limita atasat.

Anexa IV Sectiunea 6 cere "o descriere a modificarilor relevante efectuate de furnizor asupra sistemului pe parcursul ciclului sau de viata." Fiecare actualizare de algoritm, fiecare re-antrenare, fiecare modificare de arhitectura, fiecare schimbare in datele de antrenare. Documentata. Versionata. Auditabila.

Majoritatea echipelor ML cu care am vorbit nu pot nici macar sa iti spuna cate modele au in productie, daramite sa traseze fiecare model inapoi la sesiunea sa de antrenare.

Ce Cere de Fapt Anexa IV de la Stack-ul Tau MLOps

EU AI Act nu mentioneaza "registru de modele" nicaieri in text. Dar cele noua sectiuni obligatorii de documentatie din Anexa IV descriu exact ce face un registru de modele. Sa le mapam:

Sectiunea 2 (Dezvoltare si Design) cere sa documentezi "specificatiile de design, logica generala a sistemului si algoritmii utilizati," plus "seturile de date de antrenare, validare si testare: provenienta, caracteristicile, procesul de colectare, pregatire, etichetare, curatare si masurile de guvernanta" conform Articolului 10.

Tradus: ai nevoie de trasabilitatea datelor de la sursa la output-ul modelului.

Sectiunea 4 (Metrici de Performanta) cere sa descrii "adecvarea metricilor de performanta alese" si sa furnizezi rezultatele testelor inclusiv evaluari de bias pe subgrupuri de populatie.

Tradus: ai nevoie de rezultate de evaluare versionate legate de artefacte specifice ale modelului.

Sectiunea 6 (Modificari in Ciclul de Viata) cere documentarea fiecarei schimbari semnificative: actualizari de algoritm, sesiuni de re-antrenare, modificari de arhitectura, schimbari in datele de antrenare.

Tradus: ai nevoie de un changelog legat de versiunile modelului.

Sectiunea 9 (Monitorizare Post-Piata) conform Articolului 72 cere un plan de monitorizare care include detectia drift-ului de performanta si raportarea incidentelor.

Tradus: ai nevoie de monitorizare in productie legata de versiunile modelului ca sa poti corela o alerta de drift cu artefactul exact care face drift.

Iata cum arata in practica cu MLflow:

import mlflow
from mlflow.tracking import MlflowClient
 
client = MlflowClient()
 
# Register model with full lineage
with mlflow.start_run() as run:
    # Log training parameters (Annex IV Section 2)
    mlflow.log_params({
        "algorithm": "xgboost",
        "training_data_version": "v2.3.1",
        "training_data_hash": "sha256:a1b2c3d4...",
        "feature_set": "credit_scoring_v4",
        "preprocessing_pipeline": "v1.2.0"
    })
 
    # Log evaluation metrics (Annex IV Section 4)
    mlflow.log_metrics({
        "accuracy": 0.94,
        "f1_score": 0.91,
        "demographic_parity_ratio": 0.96,
        "equalized_odds_diff": 0.03
    })
 
    # Log model artifact
    mlflow.sklearn.log_model(model, "credit_model")
 
    # Register with governance metadata (Annex IV Section 6)
    model_version = mlflow.register_model(
        f"runs:/{run.info.run_id}/credit_model",
        "CreditScoringModel"
    )
 
    client.set_model_version_tag(
        "CreditScoringModel",
        model_version.version,
        "approved_by", "petru.constantin"
    )
    client.set_model_version_tag(
        "CreditScoringModel",
        model_version.version,
        "risk_classification", "high_risk_annex_iii"
    )

Asta inseamna Anexa IV Sectiunile 2, 4 si 6 in aproximativ 30 de linii de Python. Modelul, hash-ul datelor de antrenare, metricile de evaluare, masuratorile de bias si persoana care l-a aprobat. Totul versionat, totul interogabil, totul auditabil.

Diferenta Dintre "Folosim MLflow" si "Suntem Conformi"

Folosirea MLflow (sau Weights & Biases, sau SageMaker Model Registry, sau orice alt tool) nu te face automat conform. Majoritatea echipelor isi folosesc registrul de modele ca un file storage glorificat. Logheaza artefactul modelului si poate cateva metrici, apoi nu se mai uita niciodata la ele.

Conformitatea cere trei lucruri pe care majoritatea setup-urilor MLOps le omit:

1. Porti de promovare cu workflow-uri de aprobare. Un model nu poate trece din staging in productie fara aprobare umana documentata. Articolul 14 cere supraveghere umana, iar asta incepe cu cineva care aproba explicit un model pentru deployment. Nu un pipeline CI/CD care auto-promoveaza pentru ca accuracy a crescut cu 0.2%.

# Example promotion gate in CI/CD
stages:
  - name: staging
    requires:
      - bias_evaluation_passed: true
      - performance_above_threshold: true
      - data_drift_check: passed
  - name: production
    requires:
      - staging_validation: 7_days_minimum
      - human_approval: required
      - risk_assessment_updated: true
      - annex_iv_documentation: complete

2. Versionarea datelor de antrenare, nu doar a modelului. Sectiunea 2 din Anexa IV cere explicit provenienta datelor de antrenare, procesul de colectare si masurile de guvernanta. Daca re-antrenezi un model dar nu poti indica versiunea exacta a setului de date utilizat, documentatia ta Anexa IV are o lacuna. Unelte precum DVC sau lakeFS rezolva asta, dar majoritatea echipelor sar peste pentru ca "folosim mereu datele cele mai recente."

3. Monitorizare continua legata de versiunile modelului. Sectiunea 9 cere monitorizare post-piata cu detectia drift-ului de performanta. Cand dashboard-ul de monitorizare arata ca accuracy-ul scade, poti identifica imediat ce versiune de model este afectata si ce s-a schimbat de la ultima evaluare? Daca monitorizarea si registrul de modele sunt sisteme separate fara legatura intre ele, zbori pe orbeste.

Problema Retentiei de 10 Ani

Iata ceva ce majoritatea oamenilor omit: Articolul 18 cere sa pastrezi documentatia tehnica timp de 10 ani dupa ce un sistem AI cu risc ridicat este plasat pe piata.

Zece ani. Registrul tau de modele trebuie sa supravietuiasca fluctuatiei de personal, migrarilor de infrastructura si probabil cel putin doua cicluri "hai sa rescriem totul." Acea instanta MLflow care ruleaza pe o singura masina EC2? Nu va fi suficienta.

Aici maturitatea MLOps conteaza cu adevarat pentru conformitate:

• Artefactele modelului au nevoie de stocare durabila (S3 cu versionare, nu un filesystem local)
• Metadatele si trasabilitatea au nevoie de o baza de date care este backup-uita si migrata, nu un fisier SQLite
• Log-urile de acces care arata cine a aprobat ce si cand trebuie sa fie imutabile

Daca esti un startup care face deployment de AI cu risc ridicat, acesta este momentul sa alegi infrastructura care va supravietui mandatului inginerului DevOps curent.

Ce Sa Faci Saptamana Aceasta

Daca faci deployment de sisteme AI care ar putea intra sub categoriile de risc ridicat din Anexa III (credit scoring, screening HR, aplicarea legii, infrastructura critica), iata minimul de care ai nevoie:

1. Auditeaza-ti inventarul de modele. Listeaza fiecare model din productie. Daca nu le poti lista, aceasta este prima ta problema.
2. Verifica trasabilitatea. Pentru fiecare model, poti trasa inapoi la: versiunea datelor de antrenare, commit-ul codului de antrenare, rezultatele evaluarii si cine a aprobat deployment-ul? Daca vreo legatura este rupta, repareaza-o.
3. Adauga porti de promovare. Niciun model nu ajunge in productie fara aprobare documentata. Automatizeaza verificarile (bias, performanta, data drift), dar pastreaza aprobarea finala umana.
4. Configureaza versionarea datelor de antrenare. DVC, lakeFS sau chiar un bucket S3 disciplinat cu snapshot-uri imutabile. Unealta conteaza mai putin decat obiceiul.
5. Conecteaza monitorizarea la registru. Cand primesti o alerta de drift, ar trebui sa fii la un click distanta de versiunea modelului, sesiunea de antrenare si rezultatele evaluarii.

Nimic din toate astea nu necesita cumpararea unei platforme de guvernanta de 50K$. MLflow 3.0 gestioneaza registrul de modele, experiment tracking si acum trasarea agentilor GenAI out of the box. DVC gestioneaza versionarea datelor. Prometheus plus Grafana gestioneaza monitorizarea. Uneltele sunt gratuite. Disciplina este ceea ce te costa.

Avantajul de Conformitate este un Avantaj de Inginerie

Iata ce nimeni din lumea conformitatii nu iti va spune: tot ce cere Anexa IV este pur si simplu buna practica MLOps. Versionarea modelelor, trasabilitatea datelor, urmarirea evaluarilor, portile de promovare, monitorizarea. Echipele care fac asta bine livreaza modele mai bune mai repede, prind regresiile mai devreme si depaneaza problemele din productie in minute in loc de zile.

EU AI Act nu a inventat aceste cerinte. Le-a facut doar obligatorii pentru sistemele cu risc ridicat. Daca stack-ul tau MLOps face deja asta, costul conformitatii este in mare parte documentatie. Daca nu, regulamentul iti da un motiv sa construiesti infrastructura pe care ar fi trebuit sa o construiesti oricum.

La DeviDevs, am ajutat echipe sa treaca de la "avem modele undeva in S3" la pipeline-uri ML complet trasabile, pregatite pentru audit. Munca de inginerie este aceeasi indiferent daca o faci pentru conformitate sau pentru sanatatea mintala. Regulamentul doar adauga un termen limita.

Despre DeviDevs: Construim platforme ML, securizam sisteme AI si ajutam companiile sa se conformeze cu EU AI Act. devidevs.com

Sistemul tau AI e conform cu EU AI Act? Evaluare gratuita de risc - afla in 2 minute →