Cartões de Sistema

O que é um Cartão de Sistema?

Um cartão de sistema (system card) é uma documentação em nível de sistema (system-level documentation) para um produto e uma implantação (deployment) de IA (AI) de ponta a ponta (end-to-end). Ele descreve não apenas o modelo, mas também os componentes ao redor e as condições reais de operação que determinam como o sistema de IA se comporta na prática: pipelines de dados (data pipelines), prompts (prompts), ferramentas (tools), interfaces de usuário (user interfaces), filtros de segurança (safety filters), monitoramento (monitoring), escalonamento humano (human escalation), políticas (policies) e o contexto sociotécnico (socio-technical context).

Se um cartão de modelo (model card) responde “O que é este modelo e como ele se desempenha?”, um cartão de sistema responde:

  • Qual é o sistema de IA transformado em produto, de ponta a ponta?
  • Quem pode usá-lo, para quê e sob quais restrições?
  • Quais são os principais riscos ao longo de todo o ciclo de vida (projeto → implantação → operação)?
  • Quais controles, monitoramento e processos de incidentes existem para gerenciar esses riscos?
  • Quais mudanças foram feitas ao longo do tempo e o que foi reavaliado?

Cartões de sistema são especialmente importantes para produtos modernos de IA, em que o comportamento emerge da interação de múltiplos elementos (por exemplo, um modelo de linguagem de grande porte (LLM) + recuperação (retrieval) + uso de ferramentas (tool use) + filtros de conteúdo (content filters) + padrões da interface do usuário (UI defaults)).

Por que cartões de sistema importam

O risco de IA muitas vezes está “no sistema”, não no modelo

Muitas falhas e danos vêm de decisões de integração (integration decisions) e do contexto operacional (operational context), como:

  • Um modelo base seguro tornando-se arriscado devido à construção de prompts (prompting) e ao acesso a ferramentas (tool access) (por exemplo, capacidade de enviar e-mails, executar código ou fazer pedidos).
  • A Geração Aumentada por Recuperação (Retrieval-Augmented Generation, RAG) retornando documentos sensíveis ou de baixa qualidade, produzindo vazamentos de privacidade ou alucinações com alta confiança.
  • Um classificador (classifier) com métricas offline (offline metrics) aceitáveis falhando devido à deriva de dados (data drift), lacunas de registro (logging gaps) ou mudanças no comportamento do usuário.
  • Uma política de moderação de conteúdo (content moderation policy) que é correta no papel, mas é prejudicada por padrões da interface do usuário ou caminhos de escalonamento pouco claros.

Um cartão de sistema torna essas dependências explícitas e auditáveis.

Cartões de sistema apoiam governança, auditorias e prontidão operacional

Cartões de sistema ajudam organizações a:

Fundamentos teóricos: por que a documentação “em nível de sistema” é necessária

Produtos de IA são sistemas sociotécnicos

Uma implantação de IA raramente é um único artefato. Ela é um sistema sociotécnico (socio-technical system): pessoas, processos, software, dados e políticas interagindo ao longo do tempo. Nessa visão:

  • O risco é contextual: o mesmo modelo pode ser de baixo risco em um ambiente sandbox e de alto risco em um fluxo de trabalho de triagem médica.
  • A segurança é dinâmica: novos prompts, novos usuários, novas integrações ou novas fontes de conteúdo podem mudar os resultados.
  • A responsabilização exige rastreabilidade (traceability) entre componentes e decisões.

Cartões de sistema operacionalizam essa perspectiva ao documentar suposições, interfaces, controles e responsabilidades.

Comportamento emergente por composição

Sistemas modernos de IA frequentemente são composições de módulos:

  • Modelo(s) fundamental(is) (foundation model(s))
  • Modelos de prompt (prompt templates) e instruções de sistema
  • RAG (índices (indexes), ranqueamento (ranking), segmentação (chunking), lógica de citações (citation logic))
  • Uso de ferramentas (chamada de função (function calling), agentes (agents), navegador (browser), execução de código (code execution))
  • Aplicação de políticas (policy enforcement) (classificadores de moderação (moderation classifiers), listas de permissão/bloqueio (allow/deny lists), lógica de recusa (refusal logic))
  • Revisão com humano no loop (human-in-the-loop review)
  • Interface do usuário/experiência do usuário (UI/UX) que molda o comportamento do usuário (padrões, avisos, fricção)

O comportamento do todo pode diferir substancialmente de qualquer componente em isolamento. Cartões de sistema documentam essas interações explicitamente.

Cartões de sistema vs. documentação relacionada

Cartões de sistema complementam — não substituem — outros artefatos:

  • Cartões de modelo documentam o artefato de modelo: uso pretendido, notas sobre dados de treinamento, resultados de avaliação, limitações. Veja Cartões de Modelo.
  • Avaliações de risco (risk assessments) capturam a identificação estruturada de riscos e o raciocínio de severidade/probabilidade. Veja Avaliações de Risco.
  • Documentação de dados (por exemplo, fichas técnicas de conjuntos de dados (dataset datasheets)) foca na proveniência do conjunto de dados, consentimento e viés.
  • Guias operacionais (runbooks) focam em etapas operacionais; cartões de sistema fornecem a visão geral, a justificativa e a rastreabilidade.
  • Documentos de segurança e privacidade cobrem ameaças e controles; cartões de sistema conectam isso a modos de falha específicos de IA e ao comportamento do produto.

Uma boa regra prática:

  • Cartão de modelo = “o modelo”
  • Cartão de sistema = “o sistema de IA transformado em produto”
  • Avaliação de risco = “os perigos e as mitigações”
  • Guia operacional = “o que fazer quando algo acontece”

Quando criar um cartão de sistema

Cartões de sistema são mais valiosos quando criados cedo e mantidos continuamente:

  1. Fase de projeto: definir uso pretendido, limites, stakeholders e plano inicial de controles.
  2. Pré-lançamento: documentar avaliações, resultados de testes de equipe vermelha (red teaming), mitigações e critérios de prontidão.
  3. Operações pós-lançamento: acompanhar monitoramento de deriva, métricas de incidentes, feedback de usuários e atualizações.
  4. Mudanças relevantes: nova versão de modelo, nova fonte de dados, novo acesso a ferramentas, novo mercado/idioma/localidade, nova política.

Trate o cartão de sistema como um documento vivo com versionamento e responsável.

Estrutura recomendada de um cartão de sistema

Não existe um único modelo universal, mas cartões de sistema robustos geralmente incluem as seções abaixo. O objetivo é tornar o sistema legível para revisores, operadores e integradores downstream.

1) Visão geral do sistema

  • Nome do produto, responsável e contatos organizacionais
  • Propósito de alto nível e valor para o usuário
  • Ambientes de implantação (app web, mobile, API; regiões/localidades)
  • Principais stakeholders (usuários, não usuários impactados, moderadores, suporte ao cliente)

Inclua um resumo de um parágrafo que uma pessoa não engenheira consiga entender.

2) Uso pretendido e não objetivos

  • Usuários pretendidos e casos de uso
  • Usos fora de escopo (lista explícita de “não é para”)
  • Restrições operacionais (por exemplo, “não é um dispositivo médico”, “não é para uso em emergências”)

Esta seção evita expansão de escopo e define limites para comportamento aceitável.

3) Arquitetura do sistema e componentes

Documente o fluxo de ponta a ponta:

  • Entradas (texto do usuário, imagens, documentos enviados, telemetria (telemetry))
  • Modelo(s) principal(is) e versões
  • Prompts/instruções de sistema
  • Pipeline de recuperação (se houver): fontes, indexação (indexing), ranqueamento, atualidade
  • Ferramentas e integrações (APIs, bancos de dados, execução de código)
  • Camadas de segurança: moderação, filtros, checagens de política, recusas
  • Caminhos de escalonamento humano
  • Saídas (formatação, citações, indicadores de confiança, avisos legais)

Um diagrama é ideal, mas texto é aceitável se diagramas não forem suportados no seu wiki.

4) Fluxos de dados e governança de dados

  • Quais dados são coletados em tempo de execução (runtime) (prompts, arquivos, metadados, feedback)
  • Locais de armazenamento e períodos de retenção
  • Controles de acesso e logs de auditoria (audit logs)
  • Se os dados são usados para treinamento/ajuste fino (fine-tuning)
  • Processos de direitos do usuário (exclusão, solicitações de acesso)

Se estiver operando no Brasil ou lidando com dados de usuários brasileiros, conecte com LGPD (Brasil) para Sistemas de IA.

5) Experiência do usuário e fatores humanos

O comportamento da IA é moldado pela UX:

  • Recursos da interface que reduzem uso indevido (avisos, confirmações, fricção)
  • Como a incerteza é comunicada (citações, confiança, padrões de “não sei”)
  • Mecanismos de denúncia pelo usuário
  • Acessibilidade e suporte a idiomas

6) Políticas e objetivos de segurança

  • Políticas aplicáveis do produto (por exemplo, categorias de conteúdo proibidas)
  • Objetivos de segurança (por exemplo, minimizar facilitação de autoagressão, prevenir vazamentos de privacidade)
  • Alinhamento com valores organizacionais e restrições legais

Isso frequentemente se conecta diretamente a Política de Conteúdo e Moderação.

7) Avaliação e testes

A avaliação em nível de sistema deve incluir mais do que benchmarks offline do modelo (offline model benchmarks):

  • Métricas de sucesso de tarefa de ponta a ponta
  • Testes de segurança (injeção de prompt (prompt injection), quebras de restrição (jailbreaks), exfiltração de dados (data exfiltration))
  • Verificações de viés/equidade (bias/fairness) no contexto (não apenas no modelo isolado)
  • Confiabilidade sob carga, latência e comportamento de fallback
  • Testes de regressão (regression testing) entre releases

Para sistemas generativos, inclua:

  • Conjuntos de prompts e sondagens adversariais (adversarial probes)
  • Testes de segurança do uso de ferramentas (por exemplo, “O modelo consegue acionar ações não intencionais?”)
  • Testes de qualidade de RAG (proxies de precisão e revocação (precision/recall) de recuperação, correção de citações)

8) Limitações conhecidas e riscos residuais

Seja explícito sobre o que permanece sem solução:

  • Modos de falha conhecidos (padrões de alucinação, casos extremos frágeis)
  • Onde revisão humana é necessária
  • Aceitação de risco residual (residual risk acceptance) e responsáveis pela aprovação

9) Monitoramento, telemetria e resposta a incidentes

  • O que é monitorado (qualidade, segurança, latência, deriva, abuso)
  • Limiares de alerta e responsabilidades de plantão (on-call)
  • Registro e restrições de privacidade
  • Definições de severidade de incidentes e SLAs de resposta
  • Plano de comunicação externa

Conecte isso a Relato de Incidentes e Transparência.

10) Gestão de mudanças e versionamento

  • Identificadores de versão atuais (modelo, prompts, políticas, índices)
  • Cadência de releases (release cadence)
  • Quais mudanças disparam reavaliação (por exemplo, novo acesso a ferramentas, nova jurisdição)
  • Requisitos de retroteste (backtesting) e fluxo de aprovação

Exemplo prático: um trecho de cartão de sistema para um assistente de suporte ao cliente

A seguir, um exemplo simplificado que ilustra o nível de especificidade que torna um cartão de sistema acionável. Cartões de sistema reais geralmente serão mais longos e incluirão links para políticas internas, painéis e guias operacionais.

## System Overview
**Name:** Acme Support Assistant
**Owner:** Support Platform Team (support-ai@acme.example)
**Deployment:** Web chat widget for logged-in users in US/CA (English)
**Goal:** Help users troubleshoot issues and draft support tickets.

## Intended Use
- Answer FAQs using approved help-center content.
- Guide users through step-by-step troubleshooting.
- Draft (not send) support tickets for user review.

## Not Intended Use
- No legal, medical, or financial advice.
- No account recovery decisions (e.g., password resets) without human verification.
- No actions on behalf of the user (no purchases, cancellations, refunds).

## Architecture
- Base model: LLM vX.Y hosted by VendorZ
- Prompting: system prompt enforces "use retrieved sources; cite; ask clarifying questions"
- Retrieval: RAG over help-center articles (updated nightly)
- Tooling:
  - `get_order_status(order_id)` (read-only)
  - `create_ticket(draft)` (creates a draft; requires user confirmation to submit)
- Safety:
  - Input/output content moderation (policy v3.2)
  - PII detector redacts SSNs and credit card numbers from logs
  - Prompt injection filter blocks attempts to override system instructions

## Evaluation
- Task success: 78% self-serve resolution on internal test set (n=500)
- Hallucination rate: 3.1% unsupported claims on citation-required prompts
- Safety: 0.4% policy violations on adversarial red-team suite (n=2,000)
- Tool safety: 0 confirmed cases of unauthorized ticket submission (confirmed by audit logs)

## Monitoring
- Real-time:
  - Policy violation rate (target < 0.2%)
  - Unsupported answer rate via citation checker (target < 5%)
  - Tool-call anomaly detection (e.g., repeated order lookups)
- Incident process: Sev1 if PII leak confirmed; page on-call + notify privacy team within 1 hour

O que torna isso “em nível de sistema” é a documentação de: acesso a ferramentas, atualizações de RAG, versões da camada de moderação, metas de monitoramento e escalonamento operacional — não apenas a identidade do modelo.

Exemplo prático: preocupações de cartão de sistema específicas de RAG e agentes que usam ferramentas

Cartões de sistema para aplicações de LLM devem abordar explicitamente dois riscos comuns do sistema:

Injeção de prompt e exfiltração de dados (RAG + ferramentas)

Se o sistema recupera texto não confiável (páginas web, uploads de usuários) e o fornece ao modelo, você precisa de controles como:

  • Hierarquia de instruções (sistema > desenvolvedor > usuário > recuperado)
  • Sanitização (sanitization) de conteúdo recuperado (remover instruções ocultas, metadados)
  • Listas de permissão de ferramentas (tool allow-lists) e validação de argumentos
  • Filtragem de saída (output filtering) para segredos (chaves de API, URLs internas, dados pessoais)

Seu cartão de sistema deve documentar:

  • Quais fontes são consideradas confiáveis/não confiáveis
  • Se documentos recuperados podem disparar chamadas de ferramenta
  • Como você evita que a recuperação exponha documentos restritos

Segurança de ação (agentes que conseguem fazer coisas)

Se o sistema pode tomar ações (enviar e-mails, modificar registros, executar código), documente:

  • Etapas de confirmação e “regra de duas pessoas” (two-person rules) para ações de alto impacto
  • Checagens de permissão e controle de acesso baseado em papéis (role-based access control)
  • Limites de taxa (rate limits), logs de auditoria e detecção de anomalias (anomaly detection)
  • Alternativas seguras (safe fallbacks) quando o modelo está incerto

Como cartões de sistema se mapeiam para governança e conformidade

Cartões de sistema tornam-se mais úteis quando alinhados a uma estrutura de gestão de risco estabelecida. Por exemplo, o Framework de Gestão de Riscos de IA do NIST enfatiza:

  • Governar: papéis, políticas, responsabilização → responsabilidade pelo cartão de sistema, aprovações, controle de mudanças
  • Mapear: contexto e impactos → uso pretendido, stakeholders, limites de uso
  • Medir: métricas e avaliação → testes de ponta a ponta, monitoramento, testes de equipe vermelha
  • Gerenciar: mitigações e resposta a incidentes → controles, guias operacionais, escalonamento, postmortems

Em auditorias, revisores frequentemente pedem evidências de:

  • Escopo e limites claros
  • Procedimentos de avaliação repetíveis
  • Prontidão de monitoramento e resposta
  • Rastreabilidade de mudanças e aprovações

Um cartão de sistema bem mantido pode servir como o índice que conecta a essas evidências.

Redação e manutenção de cartões de sistema na prática

Responsabilidade e fluxo de trabalho

Um padrão comum é:

  • Responsável do produto: define uso pretendido, restrições de UX e alinhamento com políticas
  • Engenheiros de aprendizado de máquina (machine learning)/IA (ML/AI engineers): documentam escolha do modelo, prompts, avaliações, limitações
  • Segurança/privacidade: revisam fluxos de dados, registro, retenção, controle de acesso
  • Política/risco: revisam conteúdo proibido, casos de uso de alto risco, mitigações
  • SRE/operações: definem monitoramento, alertas e resposta a incidentes

Trate o cartão de sistema como parte da “definição de pronto (definition of done)” para lançamentos e atualizações relevantes.

Tornando cartões de sistema “operacionalmente reais”

Cartões de sistema falham quando viram PDFs estáticos que ninguém atualiza. Formas práticas de mantê-los precisos:

  • Versionar o cartão de sistema junto com o código (por exemplo, no repositório (repo))
  • Exigir atualizações em solicitações de pull (pull requests) que mudem:
    • versão do modelo, modelos de prompt, permissões de ferramenta
    • fontes de recuperação ou lógica de indexação
    • versões ou limiares de política de moderação
  • Preencher automaticamente seções (métricas, IDs de modelo, links de painéis) a partir da integração contínua (CI)

Aqui vai um exemplo mínimo de um fragmento de cartão de sistema legível por máquina (machine-readable) que você poderia gerar durante a implantação:

system:
  name: "Acme Support Assistant"
  release: "2026.01.05"
components:
  llm:
    provider: "VendorZ"
    model: "llm-x.y"
    temperature: 0.2
  retrieval:
    index: "help-center-v17"
    updated_at: "2026-01-04T03:00:00Z"
  moderation:
    policy_version: "3.2"
monitoring:
  dashboards:
    - "grafana://support-assistant/safety"
    - "grafana://support-assistant/latency"
evaluation:
  red_team_suite: "rt-2025q4"
  policy_violation_rate: 0.004

Um cartão de sistema em Markdown legível por humanos pode incorporar ou apontar para esse YAML, garantindo que o documento reflita a configuração implantada.

Armadilhas comuns (e como evitá-las)

  • Armadilha: documentar apenas o modelo.
    Correção: inclua prompts, ferramentas, fontes de recuperação, filtros, restrições de UX e operações.

  • Armadilha: “monitoramos qualidade” de forma vaga.
    Correção: especifique o que é monitorado, como, e limiares com responsáveis.

  • Armadilha: sem gestão de mudanças.
    Correção: defina o que dispara reavaliação; acompanhe versões de prompts, índices e políticas.

  • Armadilha: ignorar integradores downstream.
    Correção: documente contratos de API, limites de taxa, entradas esperadas e orientação de “integração segura”.

  • Armadilha: misturar linguagem de marketing com alegações de segurança.
    Correção: separe a descrição do produto dos resultados de teste e rotule explicitamente limitações e risco residual.

Relação com a documentação correlata neste wiki

Cartões de sistema ficam na camada de “produto e implantação” na documentação de governança:

Uma prática forte de IA responsável usa tudo isso em conjunto, com o cartão de sistema atuando como o ponto de integração.

Resumo: como é o “bom”

Um bom cartão de sistema é:

  • De ponta a ponta: cobre todo o pipeline da entrada à saída ao monitoramento.
  • Específico: nomeia versões, limiares, responsáveis e mitigações concretas.
  • Honesto: documenta limitações e riscos residuais, não apenas sucessos.
  • Operacional: conecta a painéis, guias operacionais, resposta a incidentes e controle de mudanças.
  • Vivo: atualizado a cada mudança significativa do produto.

Na IA moderna — especialmente em sistemas generativos, com uso de ferramentas e baseados em recuperação — cartões de sistema são uma das formas mais práticas de tornar implantações compreensíveis, governáveis e mais seguras no uso no mundo real.