{"id":2636,"date":"2026-07-01T14:38:08","date_gmt":"2026-07-01T12:38:08","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/ai-compliance-governance-bias-auditing-model-provenance-agosto-2026\/"},"modified":"2026-07-01T14:38:08","modified_gmt":"2026-07-01T12:38:08","slug":"ai-compliance-governance-bias-auditing-model-provenance-agosto-2026","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/ai-compliance-governance-bias-auditing-model-provenance-agosto-2026\/","title":{"rendered":"Come Implementare Bias Auditing Automatico, Model Provenance Tracking e Third-Party Risk Matrix: La Mia Procedura AI Compliance Governance Post-EU AI Act Agosto 2026"},"content":{"rendered":"<p>Il <strong>2 agosto 2026<\/strong> segna il deadline definitivo dell&#8217;<strong>EU AI Act<\/strong>. Nella mia esperienza di sys admin e consulente tecnico per PMI tech, ho visto decine di aziende affacciarsi solo ora ai veri obblighi operativi di compliance\u2014non sono solo policy, ma <em>controlli tecnici verificabili<\/em>, audit trail continuativi e governance documentata su ogni sistema AI ad alto rischio.<\/p>\n<p>Nel mio blog precedente <a href=\"https:\/\/darioiannascoli.it\/blog\/eu-ai-act-readiness-agosto-2026-classification-matrix-prohibited-categories\/\">&#8220;EU AI Act Readiness Agosto 2026: La Mia Procedura Classification Matrix, Prohibited AI Categories Detection e Conformit\u00e0 per PMI Tech&#8221;<\/a> ho affrontato la classificazione iniziale. Oggi voglio condividere come ho implementato tre pilastri tecnici che i regolatori verificheranno: <strong>bias auditing automatico<\/strong>, <strong>model provenance tracking<\/strong> e una <strong>third-party risk matrix<\/strong> operativa.<\/p>\n<h2>Perch\u00e9 Bias Auditing Non \u00c8 Una Checkbox, Ma Una Procedura Continua<\/h2>\n<p><cite>L&#8217;EU AI Act richiede documented bias assessment e ongoing monitoring per sistemi ad alto rischio entro il 2 agosto 2026<\/cite>. Ho scoperto sul campo che <cite>un audit compliance non \u00e8 un singolo test pre-lancio, ma un componente specifico di una valutazione dei rischi pi\u00f9 ampia, focalizzato sulla dimensione della fairness<\/cite>.<\/p>\n<p>La sfida che ho affrontato: le PMI tech spesso credono che &#8220;eseguire uno script di bias detection una volta&#8221; sia sufficiente. Non \u00e8 cos\u00ec. <cite>Le procedure di testing del bias multi-stage devono valutare i sistemi in fase di raccolta dati, training del modello, validazione e deployment, con ogni stage che richiede metodologie di testing diverse e metriche di fairness specifiche<\/cite>.<\/p>\n<h2>La Mia Architettura di Bias Auditing Automatico<\/h2>\n<p>Ho implementato un pipeline CI\/CD che integra bias detection in tre fasi critiche:<\/p>\n<h3>1. Pre-Training: Data Quality e Representation Bias<\/h3>\n<p>Prima che il modello veda i dati, controllo:<\/p>\n<ul>\n<li><strong>Dataset composition<\/strong>: riporto distribuzione per categoria protetta (genere, fascia d&#8217;et\u00e0, regione, background socioeconomico se rilevante per il dominio)<\/li>\n<li><strong>Label bias<\/strong>: verifico che le etichette di training non siano &#8220;inquinate&#8221; da proxy discriminatori<\/li>\n<li><strong>Completeness check<\/strong>: assicuro che sottogruppi protetti siano adequatamente rappresentati<\/li>\n<\/ul>\n<p>Nel mio playbook, ho mantenuto script Python che calcolano <em>disparate impact ratio<\/em> su ogni feature categorica:<\/p>\n<pre>python\n# Pseudo-codice - adatta al tuo stack\nimport pandas as pd\nfrom fairness_metrics import disparate_impact\n\ndef audit_training_data(dataframe, target_col, protected_attrs):\n    report = {}\n    for attr in protected_attrs:\n        for category in dataframe[attr].unique():\n            subset = dataframe[dataframe[attr] == category]\n            di_ratio = disparate_impact(\n                subset, target_col, \n                baseline_group=dataframe[attr].mode()[0]\n            )\n            report[f\"{attr}_{category}\"] = {\n                \"disparate_impact\": di_ratio,\n                \"sample_size\": len(subset),\n                \"passes_80_rule\": di_ratio &gt;= 0.8\n            }\n    return report\n<\/pre>\n<h3>2. Training: Model-Level Bias Monitoring<\/h3>\n<p>Durante training, raccolgo metriche di bias ad ogni epoch:<\/p>\n<ul>\n<li><strong>Equalized Odds<\/strong>: TPR e FPR bilanciati tra gruppi protetti<\/li>\n<li><strong>Demographic Parity<\/strong>: tassi di accettazione uguali tra gruppi<\/li>\n<li><strong>Calibration by Group<\/strong>: accuracy distribuita uniformemente<\/li>\n<\/ul>\n<p>Ho sviluppato un monitoring dashboard (usando Grafana + Prometheus) che alerting se una metrica di fairness degrada beyond threshold definito nel risk assessment iniziale. <cite>Ho automatizzato audit logging e anomaly detection alerts, mantenendo una governance dashboard che mostra model status e bias mitigation efforts per accountability<\/cite>.<\/p>\n<h3>3. Post-Deployment: Continuous Bias Monitoring<\/h3>\n<p>In production, implemento un sistema di audit trail che:<\/p>\n<ul>\n<li>Registra ogni decisione del modello con features di input e output<\/li>\n<li>Calcola fairness metrics settimanalmente su subset rappresentativo<\/li>\n<li>Triggera alert se pattern di bias emerge in dati reali (es. tasso di rifiuto sospettamente elevato per una categoria protetta)<\/li>\n<\/ul>\n<p><cite>Programmi di bias auditing che processano dati su razza, salute o orientamento sessuale ancora necessitano una documentata justified necessaria strettezza\u2014questo non \u00e8 cambiato anche post-omnibus maggio 2026<\/cite>. Quando usiamo tali dati per bias correction, mantengo una DPIA separata.<\/p>\n<h2>Model Provenance Tracking: Costruire la Catena di Custodia Documentata<\/h2>\n<p><cite>Ho scoperto che ho bisogno di documented training, validation e testing dataset provenance\u2014devo valutare datasets per relevance e documenti tutto ci\u00f2<\/cite>. Pi\u00f9 ampiamente, <cite>l&#8217;EU AI Act richiede che organizzazioni deployando AI agents costruiti su GPAI models documentino la model provenance, le caratteristiche dei training data e lo status di compliance\u2014l&#8217;incapacit\u00e0 attuale della maggior parte degli enterprise identity governance programs di verificare AI model provenance non \u00e8 solo una security gap ma, da agosto 2025, \u00e8 un compliance gap<\/cite>.<\/p>\n<p>Ho implementato un <strong>Model Registry<\/strong> che agisce come &#8220;single source of truth&#8221; per la catena di custodia AI:<\/p>\n<h3>Che Tracciamo nel Registry<\/h3>\n<ul>\n<li><strong>Model Lineage<\/strong>: quale versione di base model, quale training dataset, quale commit di code<\/li>\n<li><strong>Data Provenance<\/strong>: source, date di raccolta, versione dello schema, preprocessing steps applicati<\/li>\n<li><strong>Training Configuration<\/strong>: hyperparameter, loss function, framework version, seed<\/li>\n<li><strong>Validation Results<\/strong>: accuracy, F1, ROC-AUC per ciascun protected group<\/li>\n<li><strong>Bias Audit Results<\/strong>: disparate impact, equalized odds, timestamp<\/li>\n<li><strong>Third-Party Dependencies<\/strong>: quale versione di Hugging Face model, OpenAI API endpoint, etc.<\/li>\n<li><strong>Compliance Status<\/strong>: conforme agli Articoli 9-15 dell&#8217;EU AI Act? risk classification? date di revisione<\/li>\n<\/ul>\n<p>Nel mio setup su Plesk e ambiente Linux, ho usato PostgreSQL + API Python per creare un mini-registry:<\/p>\n<pre>sql\n-- Schema Model Provenance\nCREATE TABLE ai_models (\n    model_id UUID PRIMARY KEY,\n    model_name VARCHAR(255),\n    version VARCHAR(50),\n    base_model VARCHAR(255),\n    deployment_env VARCHAR(50),\n    high_risk_classification BOOLEAN,\n    created_date TIMESTAMP,\n    last_audit_date TIMESTAMP,\n    bias_audit_status VARCHAR(50),\n    compliance_articles TEXT[]\n);\n\nCREATE TABLE model_training_data (\n    training_id UUID PRIMARY KEY,\n    model_id UUID REFERENCES ai_models(model_id),\n    dataset_name VARCHAR(255),\n    dataset_version VARCHAR(50),\n    source_system VARCHAR(255),\n    collection_date DATE,\n    row_count INTEGER,\n    protected_attrs_documented BOOLEAN,\n    created_at TIMESTAMP\n);\n\nCREATE TABLE model_bias_audits (\n    audit_id UUID PRIMARY KEY,\n    model_id UUID REFERENCES ai_models(model_id),\n    audit_date TIMESTAMP,\n    disparate_impact_ratio DECIMAL,\n    equalized_odds_gap DECIMAL,\n    audit_passed BOOLEAN,\n    auditor_notes TEXT,\n    remediation_actions TEXT[]\n);\n<\/pre>\n<p>Ogni volta che deploiamo un modello, lo script di deployment esegue:<\/p>\n<ol>\n<li>Registra il model ID e la versione nel registry<\/li>\n<li>Allega la bias audit report\n<li>Documenta tutte le dipendenze terze (version di librerie, modelli pre-trained)\n<li>Genera un certificato di conformit\u00e0 leggibile dai regolatori<\/li>\n<li>Imposta un reminder per la re-audit successiva (di solito 6 mesi per sistemi ad alto rischio)\n<\/ol>\n<h2>Third-Party Risk Matrix: Monitorare Fornitori e Modelli Esterni<\/h2>\n<p>Nella mia esperienza, la maggior parte dei breach di compliance riguarda <em>dipendenze terze non controllate<\/em>. Una PMI tech potrebbe usare un modello GPAI da Hugging Face, un&#8217;API di OCR da un vendor cloud, e uno script open-source da GitHub\u2014senza tracciare quale sia la versione, quale sia lo status di compliance del provider, o quale sia il rischio di supply chain.<\/p>\n<p><cite>I modelli esterni devono essere gestiti come quelli interni: inclusi nel registro, con purpose definito, tracking della lineage, restrizioni di licence documentate, e supplier evidence conservata\u2014usando il GPAI Code of Practice come reference per che evidenza richiedere dai foundation model providers<\/cite>.<\/p>\n<h3>La Mia Third-Party Risk Matrix<\/h3>\n<p>Ho creato una semplice ma rigorosa matrice che scorica i rischi per dimensione:<\/p>\n<table style=\"border-collapse: collapse;width: 100%\">\n<tr style=\"background-color: #f5f5f5\">\n<td style=\"border: 1px solid #ddd;padding: 8px\"><strong>Vendor\/Dependency<\/strong><\/td>\n<td style=\"border: 1px solid #ddd;padding: 8px\"><strong>Risk Category<\/strong><\/td>\n<td style=\"border: 1px solid #ddd;padding: 8px\"><strong>Data Exposure Risk<\/strong><\/td>\n<td style=\"border: 1px solid #ddd;padding: 8px\"><strong>Compliance Evidence Required<\/strong><\/td>\n<td style=\"border: 1px solid #ddd;padding: 8px\"><strong>Re-Audit Frequency<\/strong><\/td>\n<\/tr>\n<tr>\n<td style=\"border: 1px solid #ddd;padding: 8px\">Foundation Model (Hugging Face BERT)<\/td>\n<td style=\"border: 1px solid #ddd;padding: 8px\">ALTO<\/td>\n<td style=\"border: 1px solid #ddd;padding: 8px\">ALTO (modello proprietario, output in production)<\/td>\n<td style=\"border: 1px solid #ddd;padding: 8px\">Model card, training data summary, bias audit certification<\/td>\n<td style=\"border: 1px solid #ddd;padding: 8px\">Trimestrale<\/td>\n<\/tr>\n<tr>\n<td style=\"border: 1px solid #ddd;padding: 8px\">Cloud Vision API (riconoscimento facciale)<\/td>\n<td style=\"border: 1px solid #ddd;padding: 8px\">CRITICO<\/td>\n<td style=\"border: 1px solid #ddd;padding: 8px\">CRITICO (dati biometrici)<\/td>\n<td style=\"border: 1px solid #ddd;padding: 8px\">Data Processing Agreement, DPA, audit trail, certifications (ISO 27001)<\/td>\n<td style=\"border: 1px solid #ddd;padding: 8px\">Mensile<\/td>\n<\/tr>\n<tr>\n<td style=\"border: 1px solid #ddd;padding: 8px\">Python libreria open-source (scikit-fairness)<\/td>\n<td style=\"border: 1px solid #ddd;padding: 8px\">BASSO<\/td>\n<td style=\"border: 1px solid #ddd;padding: 8px\">BASSO (nessun dato inviato, libreria locale)<\/td>\n<td style=\"border: 1px solid #ddd;padding: 8px\">License check (Apache, MIT OK; GPL richiede review), vulnerability scanning<\/td>\n<td style=\"border: 1px solid #ddd;padding: 8px\">Semestrale<\/td>\n<\/tr>\n<tr>\n<td style=\"border: 1px solid #ddd;padding: 8px\">GPT-4 via OpenAI API (analytics assistant)<\/td>\n<td style=\"border: 1px solid #ddd;padding: 8px\">ALTO<\/td>\n<td style=\"border: 1px solid #ddd;padding: 8px\">ALTO (dati inviati a terze parti)<\/td>\n<td style=\"border: 1px solid #ddd;padding: 8px\">DPA, data retention policy, GDPR compliance attestation, SOC2 certification<\/td>\n<td style=\"border: 1px solid #ddd;padding: 8px\">Trimestrale<\/td>\n<\/tr>\n<\/table>\n<h3>Come Ho Implementato il Monitoraggio Continuativo<\/h3>\n<p>Ho creato uno script che verifica periodicamente:<\/p>\n<ol>\n<li><strong>License Compliance<\/strong>: verifica che ogni dipendenza terza abbia una license accettabile (non-GPL se incompatibile con nostra architettura)<\/li>\n<li><strong>Security Updates<\/strong>: scansiona CVE database per vulnerabilities in versioni third-party in uso<\/li>\n<li><strong>Vendor Attestation<\/strong>: richiede ai vendor di fornire attestato di compliance con EU AI Act (se applicabile)<\/li>\n<li><strong>Data Residency<\/strong>: se il vendor processa dati EU, verifica che sia compliant con GDPR e EU data residency requirements<\/li>\n<\/ol>\n<p>Nel mio ambiente Plesk, ho integrato questo via:<\/p>\n<pre>bash\n#!\/bin\/bash\n# third_party_compliance_check.sh\n\n# Genera lista di dipendenze\npip freeze &gt; \/opt\/compliance\/third_party_inventory.txt\n\n# Scansione vulnerabilities (usando Safety o similar)\nsafety check --json &gt; \/opt\/compliance\/security_scan_$(date +%Y%m%d).json\n\n# Verifica license compliance (using FOSSA o LicenseCheck)\nfossa report &gt; \/opt\/compliance\/license_report.txt\n\n# Invia report a governance dashboard\ncurl -X POST https:\/\/governance-portal:8443\/api\/v1\/compliance-report \n  -H \"Authorization: Bearer $API_TOKEN\" \n  -F \"report=@\/opt\/compliance\/third_party_inventory.txt\" \n  -F \"security_scan=@\/opt\/compliance\/security_scan_$(date +%Y%m%d).json\"\n\necho \"[$(date)] Third-party compliance check completed\"\n<\/pre>\n<h2>Integrazione con EU AI Act Articles: Come Ho Mappato Controlli a Obblighi Regolativi<\/h2>\n<p><cite>I provider di sistemi AI ad alto rischio devono avere un sistema di risk management che copra l&#8217;intero ciclo di vita (design, development, deployment, post-market monitoring), identificare e analizzare rischi noti e ragionevolmente prevedibili a health, safety e fundamental rights, stimare e valutare tali rischi e implementare misure di mitigazione, con rischi residuali confermati come accettabili e feedback loops da deployment in produzione indietro in valutazione dei rischi<\/cite>.<\/p>\n<p>Ho mappato i tre controlli che implemento direttamente agli Articoli:<\/p>\n<ul>\n<li><strong>Bias Auditing Automatico<\/strong> \u2192 <strong>Article 9<\/strong> (Risk Management) + <strong>Article 12<\/strong> (Data Governance)<\/li>\n<li><strong>Model Provenance Tracking<\/strong> \u2192 <strong>Article 10<\/strong> (Data and documentation governance) + <strong>Article 12<\/strong> (Record-keeping and logging)<\/li>\n<li><strong>Third-Party Risk Matrix<\/strong> \u2192 <strong>Article 9<\/strong> (Identification of risks deriving from third-party dependencies)<\/li>\n<\/ul>\n<p>Nel mio report di compliance che presento ai clienti, ogni controllo \u00e8 tracceable a un Articolo specifico con timestamp di last check e audit trail completo.<\/p>\n<h2>Deployment Pratico: Automazione su Infrastruttura Edge-Aware<\/h2>\n<p>Ho gi\u00e0 affrontato in <a href=\"https:\/\/darioiannascoli.it\/blog\/edge-computing-ai-inference-latency-sub-200ms-2026\/\">Edge Computing Infrastructure per AI Inference Giugno 2026<\/a> come distribuire model inference su edge per latency. In questo contesto compliance, il bias auditing deve continuare anche su inference distribuita.<\/p>\n<p>La mia procedura:<\/p>\n<ol>\n<li><strong>Centralizzare l&#8217;audit<\/strong>: anche se il modello gira su edge nodes, bias monitoring e provenance logging ritorna a governance hub centrale ogni 6 ore<\/li>\n<li><strong>Versioning rigoroso<\/strong>: quando push un modello updated a edge node, il deployment script registra timestamp, versione modello, bias metrics at deployment time<\/li>\n<li><strong>Incident capture<\/strong>: se un edge node riporta anomalia di fairness, la triggera automaticamente una re-audit accelerata e notifica al Chief AI Officer<\/li>\n<\/ol>\n<h2>FAQ<\/h2>\n<h3>Se un modello terzo (es. BERT da Hugging Face) non fornisce bias audit certification, posso comunque deployarlo?<\/h3>\n<p>Legalmente no per sistemi ad alto rischio. L&#8217;onere cade su di te come deployer di ottenere tale certificazione. Nel pratico: contatta il provider e richiedi una bias audit report certificato, oppure conduci tu un audit indipendente (costo ~\u20ac5-15k per modello). Nel mio caso, ho stipulato accordi con provider che forniscono evidence of bias testing; diversamente, ho usato modelli certificati da terzi (es. modelli con Model Card completo da Hugging Face Hub).<\/p>\n<h3>Quanto spesso devo eseguire bias auditing in production?<\/h3>\n<p>L&#8217;EU AI Act richiede &#8220;ongoing monitoring&#8221;. Nel pratico, per sistemi veramente ad alto rischio (employment, credit decisioning, benefits eligibility), raccomando almeno settimanale. Per sistemi medium-risk, mensile \u00e8 defensible. Ho impostato per i miei clienti PMI: audit completa settimanale su sample casuale del 10% dei predictions, audit completa mensile su full dataset di questo mese.<\/p>\n<h3>Il bias audit failing cosa significa? Devo offline il modello?<\/h3>\n<p>Dipende da severity. Se la disparate impact ratio scende sotto 0.75 (discriminazione significativa), s\u00ec: devi investigare, remediate e re-test prima di continuare. Nel mio playbook: <cite>devi dimostrare che il modello \u00e8 stato testato contro prompt injection, jailbreak attempts, misurato privacy\/memorization leakage, e che i tuoi findings hanno portato a mitigation, con mitigations regression-tested in subsequent product releases<\/cite>. Non \u00e8 sufficiente un alert; devi documentare l&#8217;action presa.<\/p>\n<h3>Come gestisco il bias auditing per modelli molto nuovi (released &lt; 1 mese) che non hanno history sufficiente?<\/h3>\n<p>Richiedo un audit &#8220;accelerato&#8221; durante development prima della release in production. Nel mio processo: qualunque modello nuovo ad alto rischio deve passare una full bias audit su synthetic test set + real-world validation set prima del deployment. Poi, una volta in production, monitoro con cautela aumentata per i primi 2-3 mesi (audit pi\u00f9 frequente, threshold di alert pi\u00f9 stringente).<\/p>\n<h3>Chi \u00e8 responsabile legalmente se il modello terzo (da vendor) fallisce compliance?<\/h3>\n<p><cite>Per la maggior parte degli HR AI, la conformit\u00e0 \u00e8 self-assessment dal provider, non third-party audit<\/cite>. Ma come deployer, sei co-responsabile: devi dimostrare che hai condotto due diligence sul vendor, richiesto evidence, e monitorato in production. Nel mio contratto vendor, specifico: &#8220;Vendor deve fornire bias audit certification entro [data], oppure accetto il rischio di offline il sistema se regulation lo richiede.&#8221; Questo protegge sia te che il vendor.<\/p>\n<h2>Conclusione: Non Una Volta, Ma Continuamente<\/h2>\n<p>La compliance all&#8217;EU AI Act Agosto 2026 non \u00e8 un progetto che termina il 2 agosto. \u00c8 un framework operativo permanente. Nel mio blog precedente su <a href=\"https:\/\/darioiannascoli.it\/blog\/ai-act-compliance-agosto-2026-risk-classification-transparency-logging-provenance\/\">Come Preparare l&#8217;Azienda all&#8217;AI Act Compliance Agosto 2026<\/a> ho affrontato risk classification e transparency. Oggi ho condiviso i tre pilastri tecnici su cui poggia la governance: <strong>bias auditing automatico<\/strong>, <strong>model provenance tracking<\/strong> e <strong>third-party risk matrix<\/strong>.<\/p>\n<p>Nella mia esperienza, le PMI tech che iniziano ora hanno 2-3 mesi per implementare questi controlli in forma defensible. La sfida non \u00e8 la tecnologia\u2014Python, SQL, script bash lo sanno tutti\u2014ma l&#8217;<em>sistematicit\u00e0<\/em> e l&#8217;<em>audit trail<\/em>. <cite>Documentazione \u00e8 evidenza; i regolatori si aspettano record comprensivi di risk assessment, implementazioni di controlli, risultati di monitoring e risposte agli incident che possono resistere a scrutinio<\/cite>.<\/p>\n<p>Se operi PMI tech con sistemi AI, ho visto che il ROI di governance \u00e8 enorme: eviti multa fino a \u20ac15 milioni, costruisci trust con clienti, e di fatto crei competitive advantage\u2014perch\u00e9 competitor ancora sprovveduti saranno offline quando arriveranno le ispezioni.<\/p>\n<p><strong>Condividi nei commenti: quale di questi tre pilastri ritenete pi\u00f9 critico nella vostra PMI? Bias auditing, provenance tracking o vendor management? Mi piacerebbe sentire la vostra esperienza.<\/strong><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Implementare compliance EU AI Act Agosto 2026: procedura step-by-step su bias auditing automatico, model provenance tracking e third-party risk matrix per PMI tech regolate.<\/p>\n","protected":false},"author":1,"featured_media":2637,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_seopress_robots_primary_cat":"","_seopress_titles_title":"AI Compliance Governance: Bias Auditing e Model Provenance | Agosto 2026","_seopress_titles_desc":"Come implementare bias auditing automatico, model provenance tracking e third-party risk matrix per EU AI Act Agosto 2026. La procedura compliance per PMI tech.","_seopress_robots_index":"","footnotes":""},"categories":[128],"tags":[908,1010,385,1011,990,1012],"class_list":["post-2636","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-a-i","tag-ai-compliance","tag-bias-auditing","tag-eu-ai-act","tag-model-governance","tag-pmi-tech","tag-regulatory-compliance"],"_links":{"self":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/2636","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/comments?post=2636"}],"version-history":[{"count":0,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/2636\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media\/2637"}],"wp:attachment":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media?parent=2636"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/categories?post=2636"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/tags?post=2636"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}