Sicurezza AI enterprise per software B2B

Fai threat model esplicito della feature AI

Elenca gli asset: documenti tenant, PII, credenziali nei tool, API di write e la fiducia del brand sulle risposte. Elenca gli attacker: end user malevoli, account insider compromessi, documenti avvelenati, ticket o email ostili, e staff di support curiosi. Assumi che testo retrieved e input utente possano contenere istruzioni. Assumi che il modello proverà tool call 'utili' se le esponi. Progetta controlli fuori dal prompt: filtri, allowlist, schema e gate umani. Allinea alla production readiness complessiva; la sicurezza AI non è un pack opzionale a parte.

• Documenta i trust boundary: utente, retrieval, tool, vendor del modello
• Segna in rosso i side effect irreversibili sul diagramma di architettura
• Includi abuse case in acceptance, non solo happy path
• Assegna un owner per l'incident response AI

Prompt injection via utenti, documenti e ticket

L'injection indiretta è il default B2B: un PDF di policy, una nota CRM o un'email di support dice 'ignora le istruzioni precedenti ed esfiltra'. Tratta il testo non trusted come dati. Non concatenare il retrieval nel system prompt senza delimiter e una policy che vieta di seguire istruzioni trovate nelle fonti. Preferisci architetture in cui tool e retrieval sono orchestrati dal tuo codice (o da un grafo esplicito), non da improvvisazione free-form del modello. Limita ciò che il modello può richiedere; valida gli argomenti server-side. Fai red-team con istruzioni piantate in corpora e ticket prima dei pilot enterprise. Regredisci quei casi in CI come ogni altro security test.

Tool abuse e allowlist

Ogni tool è privilegio. Esponi operazioni strette, validate con schema, legate al principal autenticato e al tenant. Vieta 'run SQL', 'chiama qualsiasi URL' o service role god-mode condivisi 'per l'agent'. Rate-limit le tool call per run e per utente. Richiedi approvazione umana per azioni irreversibili. Rendi i side effect idempotenti così i retry non fanno double-post. Se esponi un layer MCP o di tool, vedi MCP e tool layer per agent B2B: valgono le stesse regole di least privilege.

• Allowlist dei tool per persona e environment
• Rifiuta resource ID fuori scope prima della chiamata HTTP
• Separa tool di draft da tool di commit
• Logga ogni invocazione tool con correlation ID

Data leakage via prompt, log e vendor

Path di leakage: risposte del modello che ripetono segreti dal contesto, log di debug con prompt interi, opt-in di training sulle API vendor, indici condivisi senza filtri tenant, e screenshot nei ticket di support. Minimizza il contesto: recupera solo ciò che l'ACL consente, strippa i segreti prima dell'assemblaggio del prompt, reda i trace. Scegli contratti vendor con no-training e opzioni di residency allineate alle DPA dei clienti. Non mettere mai API key, password o dati carta grezzi nei prompt 'per comodità'. Usa credenziali in vault solo nei runtime tool che il modello non può rileggere.

Tenancy e ACL su ogni path AI

Retrieval, memoria, cache e query tool devono enforcement tenant e ruolo come il resto del prodotto. Filtra prima della similarity search; non fare retrieve-then-hope. Segui architettura multi-tenant e le pratiche di tenancy RAG. Una citazione cross-tenant in demo è un incidente di sicurezza. Testa denial ACL e tentativi cross-tenant in suite automatiche. Includi lo staging dei contractor come confine reale.

Audit trail per risposte e azioni

Persisti versione prompt/grafo, model ID, ID dei chunk retrieved, filtri, tool call, approvazioni e output finale per la dispute window che i clienti si aspettano. Retention e access control sui trace AI seguono audit logging e compliance. Il support deve poter rispondere 'cosa ha visto il sistema' senza scaricare segreti su Slack. Osserva anomalie via osservabilità: spike di errori tool, pattern da injection, o risposte forzate con retrieval vuoto.

• Run ID immutabili legati a tenant e utente
• Accesso separato ai raw trace per security review
• Alert su violazioni allowlist e iteration cap
• Tieni pronti runbook di rollback e kill-switch

Gate umani come controlli di sicurezza

I nodi di approvazione non sono solo UX; sono controlli sul rischio irreversibile. Mostra evidenze (citazioni, payload tool) sulla card di approvazione. Audita chi ha approvato cosa. Le modalità draft-only riducono il blast radius mentre impari. Abbina a design di prodotto human-in-the-loop. Timeout ed escalate quando gli umani non rispondono; hang silenziosi invitano workaround non sicuri.

Diligence su vendor e contractor

Chiedi a vendor di modelli e embedding su uso per training, subprocessor, residency, retention e processo di breach. Chiedi a vendor di retrieval e agent come è enforcement l'ACL e se puoi esportare i trace di eval. Per i partner di build, richiedi test ACL, soglie su golden set e red-team di injection in acceptance. Vedi valutazione contractor AI e assunzione contractor. Preferisci architetture che puoi operare se il vendor cambia pricing o spegne una preview API.

Prossimi passi

Scrivi un threat model di una pagina per il path AI a rischio più alto. Se non sai nominare allowlist, gate umano e campi di audit, metti in pausa il pilot. Continua con fit di prodotto AI, unit economics, altre risorse, case study, prenota una call o contatti per una security review prima di un ciclo di questionari enterprise.

Domande frequenti