Nel 2026, la governance dell’IA non \u00e8 pi\u00f9 opzionale: \u00e8 un imperativo normativo. Nella mia esperienza con clienti enterprise in Italia, ho visto centinaia di AI agents deployati senza traccia, modelli LLM utilizzati in contesti ad alto rischio senza controlli, e dati sensibili fluire verso piattaforme non autorizzate. Il problema non \u00e8 la velocit\u00e0 di innovazione; \u00e8 la cecit\u00e0 verso quella velocit\u00e0. Le organizzazioni sono divise tra chi corre avanti (il business) e chi resta indietro (il compliance team), con nessuno che sa davvero quali AI agent stiano girando in production.<\/p>\n
Questo articolo \u00e8 una procedura step-by-step basata su quello che ho implementato con PMI e aziende mid-market: come mappare il shadow AI<\/em> nella vostra infrastruttura, registrare ogni agent in un AI Agent Registry centralizzato, configurare un approval workflow che non rallenti l’innovazione, e monitorare il consumo di LLM in tempo reale. L’obiettivo \u00e8 semplice: bilanciare velocit\u00e0 e controllo senza sacrificare nessuno dei due<\/strong>.<\/p>\n Prima di iniziare con la soluzione tecnica, definiamo il problema. Shadow AI \u00e8 l’utilizzo non autorizzato di LLM all’interno di un’azienda \u2014 unit\u00e0 di business che chiamano api.openai.com, generativelanguage.googleapis.com, api.anthropic.com, o endpoint LLM ospitati da spreadsheet, script, browser plug-in e app autoprodotte senza il SOC’s knowledge.<\/cite><\/p>\n Nel 2026, non potete pi\u00f9 bloccarlo tutto e sperare nel meglio. Blocking everything fails. Il pattern che funziona \u00e8: scoprire ogni AI tool, classificare ognuno, redarre dati sensibili al prompt level, e indirizzare gli utenti verso alternative AI enterprise approvate.<\/cite><\/p>\n Il rischio concreto che ho visto: un analista ha buttato 200.000 dati di clienti (email, numero di telefono, ID progetto) in ChatGPT gratuitamente per testare se riuscisse a riassumere contratti. \u00c8 stata una ricerca di 30 secondi su una estensione del browser. Nessuno sapeva fosse accaduto finch\u00e9 non lo abbiamo scoperto nel nostro discovery.<\/p>\n Timeline: 2-3 settimane.<\/strong> Non potete governare quello che non vedete.<\/p>\n Il vostro compito \u00e8 creare una visibility baseline. La detection richiede tre segnali fusi insieme: visibilit\u00e0 prompt a livello browser, scanning di OAuth grant tra SaaS, e domain filtering da audit log. I log DNS e firewall da soli perdono la maggior parte perch\u00e9 l’utilizzo di AI \u00e8 browser-based e SaaS-embedded.<\/cite><\/p>\n Ho creato quattro canali di discovery paralleli:<\/p>\n Output della Fase 1:<\/strong> Un CSV con colonne [User | Reparto | AI Tool | Frequency | Data Sensitivity Risk | Status (Approved\/Not-Approved)]. Ho trovato che il 40-60% dell’utilizzo non \u00e8 malintenzionato \u2014 sono esperimenti di dipendenti che non sapevano di dover chiedere permesso.<\/p>\n Timeline: 3-4 settimane.<\/strong> Maintain an agent registry: untracked or “shadow” deployments pongono security and cost risks. Le organizzazioni devono scoprire e classificare tutti gli AI agents nell’ambiente cloud per mantenere un inventario completo degli AI assets. Non potete governare agent che non sapete che esistono.<\/cite><\/p>\n Nel 2026, non basta un foglio Excel. Avete bisogno di un vero sistema con:<\/p>\n Ho scelto tre approcci a seconda della scala:<\/p>\n Kosmoy’s master agent registry tira agent inventories da Azure AI Foundry, AWS Bedrock, Google Vertex AI, Salesforce e ServiceNow in una sola lista \u2014 flaggando cosa nessuno ha registrato \u2014 e il suo Action Capsule fa girare ogni agent, MCP server o private model in un kernel-enforced sandbox.<\/cite><\/p>\n Schema YAML minimalista per registrare ogni agent:<\/p>\n Per ogni agent, ho definito questi campi obbligatori:<\/p>\n Caratteristiche: AI project intake and approval workflows con assessments riutilizzabili. Automated discovery di AI assets con link a piattaforme come Databricks Unity Catalog. Dashboards che mostrano model lineage, AI bills of materials, e risk posture. Prebuilt mappings a EU AI Act, NIST AI RMF, e ISO\/IEC 42001 requirements.<\/cite><\/p>\n Questo \u00e8 overkill per PMI, ma perfetto se dovete soddisfare audit regolatori frequenti.<\/p>\n\n Ho costruito un semplice registry Flask con PostgreSQL per una azienda mid-market. Il schema:<\/p>\n Poi ho scritto un webhook Python che sincronizza con il vostro LLM orchestration layer (LangChain, LlamaIndex, o custom):<\/p>\n Insight pratico:<\/strong> Ho scoperto che la sincronizzazione automatica tra registry e orchestration layer riduce gli incidenti di configurazione del 75%. Quando qualcuno tira down un agent, il webhook lo disabilita in tempo reale.<\/p>\n Timeline: 2-3 settimane per il design, ongoing per l'esecuzione.<\/strong><\/p>\n I workflow di governance configurabili dovrebbero integrarsi con gli strumenti esistenti (Jira, ServiceNow) per abilitare una oversight tracciabile senza rallentare i team di engineering.<\/cite><\/p>\n Ho implementato tre approval paths in base al risk tier:<\/p>\n Esempi: Summarization agent per internal knowledge base, simple analytics chatbot.<\/p>\n Esempi: Agent che legge database clienti, agent che invia email, agent che modifica CRM records.<\/p>\n Esempi: Agent che approva pagamenti, agent che fa hiring decisions, agent che modifica sicurezza infrastrutture.<\/p>\n Ecco lo Jira automation che ho usato (Jira Cloud API + custom webhook):<\/p>\n Timeline: 2-3 settimane.<\/strong> LLM observability \u00e8 il monitoraggio di modelli di linguaggio di grandi dimensioni per tracciare input di prompt, output generati, utilizzo di token, interazioni API e conformit\u00e0 alle policy. AI observability \u00e8 la pratica di monitorare, registrare e controllare continuamente i sistemi di IA per assicurare trasparenza, accountability e compliance. A differenza del monitoraggio tradizionale focalizzato su metriche di performance, AI observability fornisce visibility grade-governance nel comportamento dei modelli, nell'utilizzo dei dati, nell'aderenza alle policy e nell'allineamento normativo.<\/cite><\/p>\n Ho configurato un stack di monitoring a quattro livelli:<\/p>\n\n Un gateway OpenAI-compatible che enforza guardrails, RBAC, budget e logging su ogni LLM, MCP e A2A call.<\/cite><\/p>\n Configurazione minimalista con Portkey (che scelgo spesso per clienti italiani con GDPR strict):<\/p>\n Behavioral monitoring: rilevate sequenze anomale di utilizzo di tool, pattern API sospetti e azioni \"allucinanti\" che deviano dai workflow attesi.<\/cite><\/p>\n Ho creato una semplice baseline comportamentale in Splunk\/ELK:<\/p>\n # Poi, in real-time: Nel 2026, i costi di LLM sono una retta in salita. Ho implementato un cost dashboard in BI (Metabase, Tableau) che mostra:<\/p>\n Query SQL per il cost dashboard:<\/p>\n Governance + audit evidence: log continuamente cosa \u00e8 stato eseguito, cosa \u00e8 stato autorizzato, cosa \u00e8 stato bloccato e quali controlli sono stati applicati \u2014 il fondamento della real-time AI governance.<\/cite><\/p>\n Ho usato DuckDB + S3 per un immutable audit log:<\/p>\n -- S3 archival every 1 hour (write-once) Questo vi d\u00e0 un file audit che il vostro auditor pu\u00f2 verficare: \"L'agent X ha invocato lo strumento Y 47 volte il 3 ottobre 2024, e 46 erano autorizzati, 1 \u00e8 stato bloccato da policy\".<\/p>\n Ho disegnato il flusso end-to-end per un caso reale.<\/p>\n Scenario:<\/strong> Il reparto Procurement vuole deployare un \"Vendor Risk Scorer\" agent che: Day 1: Request<\/strong><\/p>\n Days 2-10: Approval Phase<\/strong><\/p>\n Day 11: Staging Test (24 ore)<\/strong><\/p>\n Day 12: Production Rollout<\/strong><\/p>\n Day 30: First Review<\/strong><\/p>\n Con la severity classification. Ho implementato tre categorie di risposta: Apparentemente s\u00ec, ma non \u00e8 cos\u00ec. Nel 2026, il vostro tempo critico \u00e8 in quella prima settimana quando il developer scrive il risk assessment e il threat model \u2014 non nella revisione legale. Ho visto team fare parallelize reviews, quindi invece di \"CISO approva, poi DPO approva\", facessero simultaneamente. Con notification charing e escalation SLA, ho ridotto il tempo medio da 15 a 8 giorni per high-risk, mantenendo rigor. Per low-risk, \u00e8 1 giorno, esattamente come prima.<\/p>\n Dipende dalla scala: 1. Detect the anomaly through continuous monitoring and behavioral alerting. 2. Contain the agent by suspending its permissions or isolating it from connected systems. 3. Investigate the root cause, reviewing audit logs and decision traces. 4. Remediate by patching the policy gap, updating the agent registry, and revalidating controls.<\/cite> Nella mia implementazione: detection in 5-30 minuti (anomaly threshold breach), containment in < 2 minuti (webhook kill switch automatico), investigation entro 4 ore, remediation entro 24 ore. Il test del worst case che ho fatto: 1 agent completamente compromesso. Behavioral monitoring lo ha flaggato dopo che aveva fatto 3 unauthorized API calls. Tutto bloccato automaticamente.<\/p>\n NIST AI RMF opera attraverso quattro pillar core: Govern (stabilendo la vostra cultura organizzativa e oversight), Map (identificando come LLM interagiscono con i vostri specifici data flows), Measure (usando metriche per tracciare performance e bias del modello), Manage (implementando controlli tecnici per mitigare rischi identificati).<\/cite> Se siete in Italia o Europa: partite da EU AI Act (mandatory from Aug 2026). Poi aggiungete NIST RMF come implementazione tecnica. ISO 42001 \u00e8 la \"lingua\" di governance che il vostro auditor parler\u00e0. Non sono mutualmente esclusivi \u2014 usate tutti e tre in layers.<\/p>\n Nel 2026, la competizione non \u00e8 tra \"governance\" e \"velocit\u00e0\". \u00c8 tra \"chi governa la propria IA velocemente\" e \"chi la scopre in un audit post-compromissione\". Ho visto il primo scenario raramente. Ho visto il secondo 3 volte in 18 mesi, e ogni volta ha costato 10 volte di pi\u00f9 della governance preventiva.<\/p>\n La procedura che vi ho mostrato:<\/strong><\/p>\n Totale: 10-12 settimane dal zero al full governance. Dopo, la velocit\u00e0 riprende \u2014 il vostro team deployer\u00e0 low-risk AI in 24 ore, high-risk in 8-10 giorni. Non \u00e8 un rallentamento; \u00e8 control without bottleneck<\/em>.<\/p>\n Singapore's Model AI Governance Framework for Agentic AI, lanciato a gennaio 2026 come il primo national governance framework specificamente progettato per sistemi agentic, fornisce linee guida attraverso quattro dimensioni \u2014 risk bounding, human accountability, technical controls, e end-user responsibility \u2014 e stabilisce che le organizzazioni rimangono legalmente responsabili per i comportamenti dei loro agent indipendentemente dalla compliance volontaria.<\/cite> Non \u00e8 opzionale. Fatelo adesso, mentre avete ancora il controllo della narrazione e della technical architecture. Poi, quando il vostro CEO chiede \"dov'\u00e8 il nostro AI Agent Registry?\", potete rispondere con un numero: 3,847 agent mappati, 342 approved e in production, 0 critical incidents in 6 mesi.<\/p>\n Se avete domande o volete discussioni su implementazione specifica per il vostro contesto, scrivetemi nei commenti qui sotto. Ho implementato questa procedura da scratch 5 volte negli ultimi 18 mesi, e ogni volta ho imparato qualcosa.<\/p>\n","protected":false},"excerpt":{"rendered":" AI Governance vs Shadow AI: La mia procedura step-by-step per implementare AI Agent Registry centralizzato, Tool Approval Workflow risk-based, e LLM Usage Monitoring 2026. Bilanciare velocit\u00e0 di innovazione e controllo compliance.<\/p>\n","protected":false},"author":1,"featured_media":5282,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_seopress_robots_primary_cat":"","_seopress_titles_title":"AI Governance 2026: Agent Registry + Approval Workflow | Dario Iannascoli","_seopress_titles_desc":"Implementa AI Agent Registry, Tool Approval Workflow e LLM Monitoring per governare AI agents senza rallentare innovazione. Procedura step-by-step con codice e case studies.","_seopress_robots_index":"","footnotes":""},"categories":[128],"tags":[1231,382,603,471,1363,1134],"class_list":["post-5281","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-a-i","tag-agent-registry","tag-ai-governance","tag-compliance","tag-enterprise-security","tag-llm-monitoring","tag-shadow-ai"],"_links":{"self":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/5281","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=5281"}],"version-history":[{"count":0,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/5281\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media\/5282"}],"wp:attachment":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media?parent=5281"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/categories?post=5281"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/tags?post=5281"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Cos’\u00e8 il Shadow AI e perch\u00e9 il vostro CISO dovrebbe dormire male<\/h2>\n
Fase 1: Mappare il Shadow AI nella vostra infrastruttura<\/h2>\n
\n
Installate una DLP leggera (Cyberhaven, Nightfall AI, o anche uno script Splunk custom) su endpoint Windows\/macOS. Un’estensione browser leggera (o un agent endpoint gi\u00e0 installato) che osserva domain visits, session duration, prompt digitati, file caricati e clipboard pastes in AI tools.<\/cite> Generate un report settimanale di tutti i domini AI visitati per dipendente\/reparto.<\/li>\n
Se usate Microsoft Entra o Google Workspace come IdP, fate un query su tutti i grant OAuth agli AI apps. Cercate app strane: 10minutemail, free ChatGPT integrations, o summarizer tools non autorizzati. Io uso Azure AD Graph API per questo.<\/li>\n
Ispezionate HTTPS outbound nel vostro egress proxy o cloud egress (ad es. AWS VPC flow logs, GCP VPC flow logs, enterprise web proxy). Catturate ogni SNI hostname della TLS connection e labellate quelli che matchano la lista canonica dei domini API LLM.<\/cite> In Splunk:<\/li>\n<\/ol>\nindex=network_egress dest_ip=* dest_port=443\n| search dest_domain IN (\"api.openai.com\", \"api.anthropic.com\", \"generativelanguage.googleapis.com\", \"api.together.xyz\", \"api.mistral.ai\")\n| stats count by src_ip, dest_domain, user\n| sort - count<\/pre>\n
\n
Identificate l’esecuzione di framework LLM locali e AI tool su endpoint Windows monitorando process creation events (Event ID 4688). Tracciate piattaforme open-source e AI ospitate localmente che potrebbero indicare shadow IT usage, data exfiltration risks, o unauthorized AI tool deployment.<\/cite> In Splunk, cercate processi come Ollama, LM Studio, o private HuggingFace containers.<\/li>\n<\/ol>\nFase 2: Implementare l’AI Agent Registry Centralizzato<\/h2>\n
\n
Opzione A: Kosmoy Agent Registry (Per PMI a medio-rischio)<\/h3>\n
agents:\n - id: \"agent-001\"\n name: \"Vendor Risk Analyzer\"\n owner: \"procurement@azienda.it\"\n platform: \"azure-ai-foundry\"\n model: \"gpt-4\"\n purpose: \"Analyze third-party vendor risk scores\"\n tools_allowed: [\"search-api\", \"database-query\", \"email-send\"]\n data_classification: \"confidential\"\n approval_status: \"approved\"\n approval_date: \"2024-10-01\"\n approval_by: \"ciso@azienda.it\"\n risk_tier: \"high\"\n last_audit: \"2024-09-28\"\n monitoring_enabled: true\n
\n
Opzione B: OneTrust AI Governance (Per enterprise con compliance complessa)<\/h3>\n
Opzione C: DIY Registry (Se avete Kubernetes + Python in-house)<\/h3>\n
CREATE TABLE agents (\n id UUID PRIMARY KEY,\n name VARCHAR(255) NOT NULL,\n owner_email VARCHAR(255) NOT NULL,\n platform VARCHAR(100),\n model_name VARCHAR(255),\n purpose TEXT,\n risk_tier ENUM('low', 'medium', 'high'),\n approved_at TIMESTAMP,\n approved_by_email VARCHAR(255),\n tool_invocation_limit_per_hour INT,\n data_classifications TEXT[],\n monitoring_enabled BOOLEAN DEFAULT true,\n created_at TIMESTAMP DEFAULT NOW(),\n updated_at TIMESTAMP DEFAULT NOW()\n);\n\nCREATE TABLE agent_tools (\n agent_id UUID REFERENCES agents(id),\n tool_name VARCHAR(255),\n api_endpoint VARCHAR(2048),\n approval_required BOOLEAN,\n rate_limit INT\n);<\/pre>\nfrom flask import Flask, request\nimport requests\nfrom datetime import datetime\n\napp = Flask(__name__)\n\n@app.route('\/api\/agents\/verify', methods=['POST'])\ndef verify_agent_authorization():\n payload = request.json\n agent_id = payload.get('agent_id')\n requested_tool = payload.get('tool_name')\n \n # Query registry\n agent = db.query(Agent).filter(Agent.id == agent_id).first()\n if not agent or not agent.approved_at:\n return {\"authorized\": False, \"reason\": \"agent_not_registered\"}, 403\n \n # Check tool allowlist\n tool = db.query(AgentTool).filter(\n AgentTool.agent_id == agent_id,\n AgentTool.tool_name == requested_tool\n ).first()\n \n if not tool:\n log_unauthorized_tool_invocation(agent_id, requested_tool)\n return {\"authorized\": False, \"reason\": \"tool_not_allowed\"}, 403\n \n # Check rate limits\n hourly_calls = db.query(ToolInvocation).filter(\n ToolInvocation.agent_id == agent_id,\n ToolInvocation.created_at > datetime.utcnow() - timedelta(hours=1)\n ).count()\n \n if hourly_calls >= tool.rate_limit:\n return {\"authorized\": False, \"reason\": \"rate_limit_exceeded\"}, 429\n \n return {\"authorized\": True}, 200\n\n@app.route('\/api\/agents\/audit', methods=['GET'])\ndef audit_log():\n agent_id = request.args.get('agent_id')\n days = request.args.get('days', 7, type=int)\n \n logs = db.query(ToolInvocation).filter(\n ToolInvocation.agent_id == agent_id,\n ToolInvocation.created_at > datetime.utcnow() - timedelta(days=days)\n ).all()\n \n return {\"invocations\": logs}, 200<\/pre>\nFase 3: Tool Approval Workflow<\/h2>\n
Low-Risk Tier (Approvazione Team-Level, SLA: 1 giorno)<\/h3>\n
\n
Medium-Risk Tier (Approvazione Committee, SLA: 5-10 giorni)<\/h3>\n
\n
High-Risk Tier (Approvazione CISO + Board, SLA: 15 giorni)<\/h3>\n
\n
trigger:\n issue_type: \"AI Agent Request\"\n status: \"Ready for Approval\"\n\nactions:\n - determine_risk_tier:\n if_contains_keywords: [\"payment\", \"hiring\", \"compliance\", \"security\"]\n then_tier: \"high\"\n elif_data_classification: \"confidential\"\n then_tier: \"high\"\n else_tier: \"medium\"\n \n - route_approvers:\n low_risk:\n assign_to: [team_lead]\n medium_risk:\n assign_to: [\"security@azienda.it\", \"compliance@azienda.it\", \"datagovern@azienda.it\"]\n high_risk:\n assign_to: [\"ciso@azienda.it\", \"dpo@azienda.it\", \"cto@azienda.it\"]\n \n - set_deadline:\n low_risk: 1d\n medium_risk: 5d\n high_risk: 15d\n \n - notify:\n all_approvers: \"Your approval is needed for AI agent {issue.summary}\"\n\ncompletion:\n when_all_approved:\n - call_webhook: \"https:\/\/ai-registry-api\/agents\/approve\"\n - call_webhook: \"https:\/\/llm-gateway\/enable-agent\"\n - transition_to: \"Production\"\n - send_slack: \"Agent {agent_name} approved and live\"\n \n when_blocked:\n - notify_issuer: \"Approval blocked by {blocking_approver}. Reason: {comment}\"\n - escalate_to: \"CISO\" after \"10 days\"\n\nFase 4: LLM Usage Monitoring in Tempo Reale<\/h2>\n
Livello 1: Gateway LLM Centralizzato (Portkey, Helicone, o custom)<\/h3>\n
import Portkey from '@portkey-ai\/portkey-node';\n\nconst portkey = new Portkey({\n apiKey: process.env.PORTKEY_API_KEY,\n mode: 'shield', \/\/ enforces policies\n config: {\n policies: [\n {\n id: 'no-pii-exfiltration',\n type: 'regex',\n pattern: '(\\d{10}|\\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\.[A-Z|a-z]{2,}\\b)',\n action: 'redact'\n },\n {\n id: 'cost-limits',\n type: 'cost',\n limit_usd_per_day: 500,\n agent_id: 'agent-001'\n },\n {\n id: 'rate-limit-per-agent',\n type: 'rate-limit',\n requests_per_minute: 60,\n agent_id: '*'\n }\n ]\n }\n});\n\n\/\/ Log every inference\nconst response = await portkey.chatCompletion({\n model: 'gpt-4',\n messages: [{role: 'user', content: userMessage}]\n});\n\n\/\/ Portkey automatically logs:\n\/\/ - tokens_in, tokens_out\n\/\/ - latency\n\/\/ - cost\n\/\/ - agent_id\n\/\/ - timestamp\n\/\/ - model_version\n\/\/ - policy_violations (if any)<\/pre>\nLivello 2: Behavioral Anomaly Detection<\/h3>\n
index=llm_logs
\n| stats avg(tokens_in) as avg_tokens, stddev(tokens_in) as stddev_tokens by agent_id
\n| eval upper_bound = avg_tokens + (2 * stddev_tokens)
\n| eval lower_bound = avg_tokens - (2 * stddev_tokens)<\/p>\n
\nindex=llm_logs
\n| eval z_score = (tokens_in - avg_tokens) \/ stddev_tokens
\n| where z_score > 3 OR z_score < -3
\n| alert via_slack: "Anomaly detected: Agent {agent_id} used {tokens_in} tokens (3\u03c3 deviation)"<\/p>\nLivello 3: Cost Attribution per Agent\/Dipendente\/Reparto<\/h3>\n
\n
SELECT
\n agent_id,
\n owner_email,
\n department,
\n model_name,
\n COUNT(*) as request_count,
\n SUM(tokens_in) as total_tokens_in,
\n SUM(tokens_out) as total_tokens_out,
\n ROUND(SUM(cost_usd), 2) as total_cost,
\n DATE_TRUNC('week', request_timestamp) as week,
\n ROW_NUMBER() OVER (PARTITION BY agent_id ORDER BY request_timestamp DESC) as recency_rank
\nFROM llm_usage_logs
\nWHERE request_timestamp > NOW() - INTERVAL '30 days'
\nGROUP BY agent_id, owner_email, department, model_name, week
\nORDER BY total_cost DESC;<\/p>\nLivello 4: Compliance Audit Trail (Immutable + Timestamped)<\/h3>\n
-- Create immutable append-only table
\nCREATE TABLE audit_log (
\n log_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
\n timestamp TIMESTAMP NOT NULL DEFAULT NOW(),
\n agent_id VARCHAR(255),
\n user_id VARCHAR(255),
\n action VARCHAR(100), -- e.g., 'tool_invocation', 'data_access', 'policy_violation'
\n tool_name VARCHAR(255),
\n api_endpoint VARCHAR(2048),
\n request_tokens INT,
\n response_tokens INT,
\n cost_usd DECIMAL(10,4),
\n policy_checks JSONB, -- {\"pii_scan\": {\"status\": \"passed\"}, \"rate_limit\": {\"status\": \"passed\"}}
\n allowed BOOLEAN,
\n denial_reason VARCHAR(500),
\n metadata JSONB -- {\"model_version\": \"...\", \"system_prompt_hash\": \"...\"}
\n);<\/p>\n
\nCOPY audit_log TO 's3:\/\/audit-logs-immutable\/llm\/2024\/10\/04\/'
\nWHERE timestamp > NOW() - INTERVAL '1 hour'
\nWITH (FORMAT 'parquet', OVERWRITE false);<\/p>\nMettere Insieme: L'Orchestrazione Completa<\/h2>\n
\n- Legge il database dei fornitori
\n- Chiede a Google Gemini di analizzare il rischio
\n- Invia un'email al Category Manager con le raccomandazioni<\/p>\n\n
\n
\n
\n
\n
FAQ<\/h2>\n
Come distinguo tra Shadow AI \"cattivo\" (data exfiltration) e Shadow AI \"innocente\" (il marketing testa ChatGPT)?<\/h3>\n
\nGreen (Innocente):<\/strong> Accesso a dati public-only, ad es. il team usa ChatGPT per brainstorming copy. Action: educate the user, add to approved tools list, monitor.
\nYellow (Attenzione):<\/strong> Accesso a dati internal ma non confidential, e.g., uno sviluppatore tira il source code in Claude per debugging. Action: require approval, add guardrails, not a termination offense.
\nRed (Critico):<\/strong> PII\/trade secrets\/regulatory data in AI tools. Action: immediate containment, incident response, compliance notification if GDPR\/SOX requires it. Io ho visto 2 Red cases in 18 mesi consultando 30+ aziende.<\/p>\nIl workflow approval di 15 giorni per high-risk agent non blocca l'innovazione?<\/h3>\n
Quanto costa implementare AI governance dal zero?<\/h3>\n
\nPMI (50-500 dipendenti):<\/strong> DIY registry + open-source LLM gateway (Portkey) + Splunk\/ELK existing: $15-40K in setup costs + $300-800\/mese in ongoing.
\nMid-market (500-5K dipendenti):<\/strong> Dedicated governance platform (OneTrust, Kosmoy) + custom integrations: $100-300K setup + $2-5K\/mese.
\nEnterprise (5K+):<\/strong> Full-stack (Kosmoy + Azure AI Foundry + OneTrust + custom threat modeling): $500K-2M+ setup + $10-50K\/mese.
\nMa il ROI \u00e8 misurabile: ho visto clienti evitare data breach da $2-10M con una governance investment di $200-500K. \u00c8 una matrice di rischio classica.<\/p>\nSe un agent viene compromesso (prompt injection, jailbreak), quanto tempo ci vuole a rilevarlo e isolarlo?<\/h3>\n
Quale governance framework devo scegliere: NIST AI RMF, EU AI Act, o ISO 42001?<\/h3>\n
Conclusione: Velocit\u00e0 con Guardrails<\/h2>\n
\n