ARTFEED — Contemporary Art Intelligence

I Sistemi AI Agentici Violano le Assunzioni Fondamentali del Design dei Database

ai-technology · 2026-04-27

I carichi di lavoro AI agentici violano sistematicamente le assunzioni implicite alla base dell'architettura tradizionale dei database, trasformando quelle che un tempo erano best practice opzionali in infrastrutture portanti. Per quarant'anni, i database sono stati progettati per applicazioni deterministiche e scritte da umani, con query prevedibili, scritture intenzionali, connessioni brevi e guasti rumorosi. I sistemi AI agentici ragionano per arrivare alle query, producendo join imprevedibili e mantenendo le connessioni durante le pause di inferenza LLM. Scrivono in modo autonomo, potenzialmente ritentando operazioni con dati incompleti, e possono esaurire i pool di connessioni attraverso sotto-agenti paralleli. L'articolo documenta un fallimento reale in cui un agente ha elaborato 500 transazioni con dati incompleti dopo un guasto silenzioso dell'API. Le mitigazioni includono timeout delle istruzioni a livello di ruolo, soft delete con colonne di identità dell'agente, log degli eventi append-only con chiavi di idempotenza, pool di connessioni dedicati con PgBouncer in modalità transaction pooling, tagging delle query per l'osservabilità specifica dell'agente e design dello schema ottimizzato per la leggibilità LLM. L'autore sostiene che pattern come ruoli con privilegi minimi, sicurezza a livello di riga e chiavi di idempotenza devono essere implementati come strati difensivi, assumendo che il chiamante possa essere errato, ritentare e non monitorare i risultati. Non è richiesta nuova tecnologia, solo un cambiamento nel trattare il database come strato difensivo.

Fatti principali

  • I sistemi AI agentici violano il contratto implicito del design dei database simultaneamente a ogni livello.
  • I database tradizionali presupponevano query deterministiche e scritte da umani, sottoposte a revisione del codice e test.
  • Gli agenti ragionano per arrivare alle query, producendo join imprevedibili e mantenendo le connessioni durante le pause LLM.
  • Un fallimento documentato ha coinvolto un agente che ha elaborato 500 transazioni con dati incompleti dopo un guasto silenzioso dell'API.
  • I timeout delle istruzioni dovrebbero essere impostati a livello di ruolo, non solo a livello di applicazione.
  • Si raccomandano soft delete con una colonna deleted_by per qualsiasi tabella su cui un agente può scrivere.
  • I log degli eventi append-only con chiavi di idempotenza prevengono scritture duplicate da ritentativi dell'agente.
  • PgBouncer in modalità transaction pooling può servire 500 connessioni di agenti utilizzando solo 20 connessioni Postgres effettive.
  • I commenti delle query con agent_id, task_id e step consentono l'osservabilità specifica dell'agente.
  • Lo schema dovrebbe essere progettato per la leggibilità LLM con nomi di colonna descrittivi e commenti simili a docstring.
  • L'accesso per ruolo per tipo di agente con privilegi minimi riduce il raggio d'esplosione di agenti malfunzionanti.
  • I pattern richiesti non sono nuovi, ma diventano infrastruttura portante sotto carichi di lavoro agentici.

Entità

Istituzioni

  • Postgres
  • PgBouncer

Fonti