Pular para conteúdo

DCP-AI e o Regulamento de IA da UE — correspondência das obrigações de registro, supervisão humana e manutenção de registros

Tradução informativa da versão em inglês, atualizada em 28/10/2026. Em caso de divergência, prevalece a versão em inglês. Identificadores, comandos e blocos de código são mantidos sem tradução.

Versão da especificação: 2.0 Última atualização: outubro de 2026 Data da revisão jurídica: 22/10/2026 Status: Informativo. As fontes jurídicas foram lidas em 22/10/2026 (seção 7); a correspondência de implementação descreve as especificações, schemas e SDKs de main em 25/10/2026 e indica onde a tag histórica do repositório v2.10.0 (22/10/2026) difere, e onde uma especificação exige algo que as funções dos SDKs não fazem. Essa tag não é a publicação atual nem o pacote Python dcp-ai 2.10.0 verificado em 26/10/2026; as versões atuais estão em Versões publicadas

Nota (27/10/2026). Apenas a linha sobre a cadeia de hash duplo da seção 3 (art. 19(1) e art. 26(6)) incorpora o trabalho de 27/10/2026 no código-fonte ainda não publicado sobre os campos secundários SHA3-256. A data de leitura jurídica (22/10/2026) e o retrato da implementação de 25/10/2026 do restante deste documento não mudam.

Nota (28/10/2026). Essa linha agora remete às versões de correção SHA3 publicadas em 28/10/2026; o restante deste documento não muda, exceto o item da lista de verificação sobre o cache de verificação, que agora separa os pacotes publicados do código-fonte não publicado de main.

Este documento faz a correspondência entre as obrigações do Regulamento (UE) 2024/1689 (o «Regulamento de IA»), alterado pelo Regulamento (UE) 2026/1744 (o «Digital Omnibus on AI»), relativas a rastreabilidade, registro, supervisão humana, manutenção de registros, explicação e evidência de incidentes e os artefatos, serviços e funções dos SDKs do DCP-AI. Segue a estrutura de NIST_CONFORMITY.md: seções numeradas, uma tabela de correspondência, uma lista de verificação para implementadores e uma lista explícita de lacunas.

Todos os artigos citados abaixo foram lidos em 22/10/2026 no texto oficial do EUR-Lex. O texto de base é o regulamento tal como publicado (CELEX 32024R1689); as alterações vêm do Digital Omnibus on AI tal como publicado no Jornal Oficial. A seção 4 indica de que texto vem cada data. Quando o texto cita o regulamento, as citações se limitam a poucas palavras e são mantidas em inglês, tal como lidas no EUR-Lex; todo o resto é paráfrase e não deve ser lido como a redação jurídica.

1. Escopo e ressalva

O DCP-AI é um protocolo e um formato de evidência. Ele define artefatos assinados (em um bundle, o Responsible Principal Record, o Agent Passport, a Intent e a Policy Decision são, cada um, um SignedPayload; os registros de ciclo de vida, disputas, direitos e delegação são assinados por suas próprias funções), entradas de auditoria com as quais um bundle assinado se compromete pela sua raiz de Merkle de auditoria em vez de assiná-las uma a uma, uma trilha de auditoria que permite detectar adulterações, ancoragem e log de transparência opcionais e verificadores locais, cada um dos quais checa só o que a sua rota cobre (por exemplo, verifySignedBundleV2 para um bundle V2).

O DCP-AI não é:

  • uma avaliação da conformidade, uma norma harmonizada, uma especificação comum nem uma presunção de conformidade nos termos do Regulamento de IA;
  • um sistema de gestão de riscos (art. 9), um sistema de gestão da qualidade, documentação técnica (art. 11) nem um plano de acompanhamento pós-comercialização (art. 72) de nenhum sistema de IA específico;
  • aconselhamento jurídico. Se um determinado agente é um «sistema de IA», se é de risco elevado e quem é o prestador ou o responsável pela implantação são determinações que a organização deve fazer com sua assessoria jurídica.

O que este documento faz é mais limitado: para cada obrigação listada, ele nomeia o mecanismo do DCP que produz evidência ou aplica um controle, diz até onde esse mecanismo vai (supports, partial, out of scope) e indica o que o prestador ou o responsável pela implantação ainda precisa fazer por conta própria. Uma linha marcada como supports significa que o mecanismo existe e faz o que a linha diz quando configurado como descrito na seção 5; não significa que a obrigação esteja cumprida.

Valores de cobertura usados na seção 3:

Valor Significado
supports Um artefato do DCP, uma regra do verificador ou um serviço de referência implementa o mecanismo que a obrigação exige. Operá-lo corretamente continua sendo tarefa da organização (seção 5).
partial O DCP produz evidência ou uma peça de construção, mas uma parte substancial da obrigação (um documento, um processo, um relatório, uma decisão humana) não é algo que o protocolo possa produzir.
out of scope O DCP não trata disso e não deve ser citado para isso.

2. Papéis: prestador e responsável pela implantação versus operador, principal responsável e agente

O Regulamento de IA vincula as obrigações a papéis definidos no art. 3. Um prestador (art. 3(3)) desenvolve um sistema de IA, ou o manda desenvolver, e o coloca no mercado ou em serviço em seu próprio nome. Um responsável pela implantação (art. 3(4)) usa um sistema de IA «under its authority», exceto em atividade pessoal não profissional. Um sistema de IA (art. 3(1)) é um sistema baseado em máquina que funciona com «varying levels of autonomy» e que infere, a partir da entrada que recebe, como gerar resultados. As obrigações do Regulamento se vinculam ao sistema de IA e às pessoas jurídicas por trás dele.

Os papéis do DCP se vinculam a uma instância de agente e à pessoa ou organização que responde por ela:

Papel no DCP Onde é registrado Papel típico no Regulamento de IA Notas
Principal responsável schemas/v2/responsible_principal_record.schema.json: human_id, legal_name, entity_type (natural_person ou organization), jurisdiction, liability_mode (owner_responsible), override_rights, binding_keys Responsável pela implantação, ou a pessoa física a quem o responsável pela implantação atribui a supervisão humana nos termos do art. 26(2) O RPR nomeia quem responde pelas ações do agente. Quando entity_type é organization, costuma ser o próprio responsável pela implantação; quando é natural_person, costuma ser a pessoa dentro do responsável pela implantação que detém os override_rights.
Agente schemas/v2/agent_passport.schema.json: agent_id, keys, principal_binding_reference, capabilities, risk_tier, status O sistema de IA (ou um componente dele) Um agente DCP é uma instância implantada com suas próprias chaves e seu próprio estado de ciclo de vida. O prestador do modelo ou do framework subjacente não aparece em nenhum artefato do DCP.
Operador (de um serviço de verificação, um motor de políticas, um log de transparência, um serviço de ancoragem ou de revogação) server/, services/, política do verificador (OPERATOR_GUIDE.md) Normalmente o responsável pela implantação; pode ser o prestador quando o prestador distribui o controle como parte do sistema, ou um terceiro O operador decide a política do verificador, a retenção dos dados de auditoria e a cadência de ancoragem. Vários itens da seção 5 cabem ao operador.
Agente contraparte (DCP-04, DCP-09) interaction_record.counterparty_agent_id, mandatos de delegação Outro sistema de IA, possivelmente de outro responsável pela implantação Os registros de interação dão a cada parte evidência do mandato da outra.

Duas consequências para a correspondência:

  1. As obrigações do lado do prestador são em sua maioria partial. O DCP não conhece o modelo, os dados de treinamento nem a finalidade prevista. Ele pode documentar como funciona a camada de responsabilização (seção 3, linha do art. 11), não o sistema de IA em si.
  2. As obrigações de registro e supervisão do lado do responsável pela implantação são onde o DCP é mais forte. O controle de intenções, as decisões de política, a cadeia de auditoria, os override_rights do RPR, as declarações de aconselhamento e os estados de ciclo de vida são controles voltados ao responsável pela implantação que produzem evidência assinada.

As especificações do DCP-AI usam «human» e «principal» para a pessoa vinculada pelo RPR. Este documento usa «principal responsável» para essa pessoa, e «responsável pela implantação» e «prestador» no sentido do Regulamento.

3. Tabela de correspondência

Cada linha: o artigo tal como lido no EUR-Lex, uma paráfrase breve da obrigação, o mecanismo do DCP com referências precisas, a cobertura e o que a organização ainda precisa fazer. As referências à especificação remetem a spec/DCP-AI-v2.0.md («core §n») e às especificações de perfil spec/DCP-05.md a spec/DCP-09.md. Os nomes de funções são do SDK TypeScript (@dcp-ai/sdk, sdks/typescript/src/index.ts); os SDKs Python, Go, Rust e WASM cobrem, cada um, um subconjunto diferente com sua própria nomenclatura; portanto, consulte o README de cada SDK para ver o que ele expõe (veja também API_REFERENCE.md).

3.1 Registro e evidência de adulteração

Artigo Obrigação (paráfrase) Mecanismo do DCP Cobertura O que fica para a organização
Art. 12(1) Os sistemas de risco elevado devem permitir tecnicamente o registro automático de eventos (logs) ao longo de sua vida útil. Cada ação controlada produz uma entrada de auditoria com a qual o bundle assinado se compromete pela raiz de Merkle da auditoria (as entradas não são assinadas uma a uma; schemas/v2/audit_entry.schema.json: audit_id, timestamp, agent_id, human_id, intent_id, intent_hash, policy_decision, outcome, evidence). O SDK não controla ações nem grava logs por conta própria: a aplicação constrói cada entrada e a passa ao construtor (BundleBuilderV2, com prevHashForEntry e intentHash como auxiliares). DCP-05 §9, DCP-07 §9, DCP-08 §8 e DCP-09 §9 especificam entradas de auditoria para os eventos de ciclo de vida, disputas, direitos e delegação; as funções do SDK para esses eventos não as criam automaticamente, então a aplicação precisa fazê-lo. supports Encaminhar toda ação relevante do sistema de IA pelo controle de intenções e gravar a sua entrada de auditoria. As ações feitas fora do DCP (inferência do modelo, eventos da interface, chamadas de ferramentas não declaradas como intenções) não são registradas pelo DCP.
Art. 12(2) O registro deve dar rastreabilidade adequada à finalidade prevista: eventos relevantes para identificar situações de risco, para o acompanhamento pós-comercialização (art. 72) e para o monitoramento do responsável pela implantação (art. 26(5)). Cada entrada de auditoria vincula a intenção (intent_id, intent_hash = SHA-256 da intenção canônica, DCP-03), o resultado da política (policy_decision: approved, escalated, blocked), o resultado (outcome) e a Action Evidence (evidence.tool, evidence.result_ref, evidence.evidence_hash). A Policy Decision traz risk_score (inteiro 0..1000), reasons, applied_policy_hash e resolved_tier. Todos os artefatos de uma sessão compartilham um session_nonce (core §8). supports Definir action_type, data_classes e estimated_impact de modo que reflitam a finalidade prevista do sistema; manter as versões da política por trás de applied_policy_hash para que uma decisão possa ser relida depois.
Art. 12(3) Para sistemas de identificação biométrica à distância (anexo III, ponto 1(a)): período de cada utilização, base de dados de referência, dados de entrada correspondentes, identidade das pessoas físicas que verificaram o resultado. Só o último item tem equivalente: schemas/v2/human_confirmation.schema.json registra human_id, intent_id, decision (approve/deny) e uma assinatura composta. O DCP não tem campos para bases de dados de referência nem para entradas correspondentes. out of scope O conteúdo de registro específico da biometria é projeto do prestador. As Human Confirmations podem evidenciar quem confirmou um resultado, não a correspondência em si.
Art. 19(1) e art. 26(6) Os prestadores (art. 19) e os responsáveis pela implantação (art. 26(6)) mantêm sob seu controle os logs gerados automaticamente por um período adequado à finalidade prevista, «of at least six months», salvo disposição em contrário do direito da União ou nacional (em especial o de proteção de dados). Evidência de adulteração do que é mantido: a cadeia de hash (prev_hash, DCP-03), a cadeia de hash duplo (prev_hash_secondary, hash_alg: "sha256+sha3-256", core §10.3, spec/VERIFICATION.md V2-11), as raízes de Merkle do manifesto do bundle (audit_merkle_root, audit_merkle_root_secondary, audit_count; merkleRootForAuditEntries, dualMerkleRoot), os checkpoints PQ (schemas/v2/pq_checkpoint.schema.json, createPQCheckpoint, PQCheckpointManager, core §10.2) e os checkpoints de compactação (schemas/v2/audit_compaction.schema.json, createAuditCompaction em sdks/typescript/src/core/audit-compaction.ts, core §10.4) permitem a um verificador detectar, em qualquer data posterior, se um log mantido foi alterado desde que foi comprometido. Os pacotes dos SDKs publicados antes de 28/10/2026 checam a cadeia primária e a raiz de Merkle, mas não a cadeia secundária nem audit_merkle_root_secondary; os verificadores desde @dcp-ai/sdk 2.2.1, @dcp-ai/wasm 2.1.1, dcp-ai 2.10.1 (PyPI), Go v2.11.1 e Rust dcp-ai 2.11.1 verificam os campos secundários presentes, portanto confie nos compromissos secundários como evidência verificada apenas com um verificador que inclua essa verificação (STORAGE_AND_ANCHORING.md). A retenção em si: o DCP não define nenhum período de retenção nem nenhum armazenamento. STORAGE_AND_ANCHORING.md lista as opções de armazenamento (bundle portátil em poder do titular, hashes ancorados, revogações distribuídas); OPERATOR_GUIDE.md informa que o gateway e os serviços de referência guardam o estado em memória, a menos que o serviço de revogação tenha REVOCATION_STATE_PATH em um armazenamento persistente, e que «a restart, a deploy or a crash wipes their state». DCP-08 §3.5 (Immutable Record) diz que os registros de auditoria, vitalidade e ciclo de vida «shall be preserved intact for the retention period specified in the commissioning certificate and decommissioning record», e o exemplo de declaração de direitos do DCP-08 usa minimum_retention_period: "P7Y", mas nenhum campo de schema impõe um período. partial Guardar os bundles assinados e as entradas de auditoria (não só seus hashes) em armazenamento durável por pelo menos seis meses, por mais tempo quando a finalidade prevista ou a regulação setorial exigirem. A compactação (core §10.4) permite arquivar os eventos compactados enquanto o checkpoint permanece na cadeia ativa; os eventos arquivados ainda devem ser mantidos durante o período de retenção. Arquivar as chaves públicas dos agentes na desativação (DCP-05 §8.4) para que as assinaturas antigas continuem verificáveis. Decidir a base do RGPD para manter as entradas que trazem human_id e aplicar o RPR cego (linha 3.7) quando as entradas saírem da organização.
Art. 26(6), segundo parágrafo, art. 19(2) As instituições financeiras mantêm os logs como parte da documentação exigida pelo direito da União em matéria de serviços financeiros. Os bundles e as entradas de auditoria são JSON portátil (CBOR opcional, core §16) e podem ser arquivados dentro de um sistema de registros existente. partial Fazer o arquivo de bundles corresponder ao calendário de retenção de registros já vigente pela regulação de serviços financeiros.
Art. 73(6), segundo parágrafo Após um incidente grave, o prestador não deve alterar o sistema de IA de forma que afete a avaliação posterior de suas causas antes de informar as autoridades. A ancoragem (services/anchor, anchor_receipt em STORAGE_AND_ANCHORING.md) e o log de transparência (services/transparency-log: POST /add, GET /proof/:index, GET /root/signed, árvore da RFC 6962, cabeças de árvore assinadas com Ed25519) registram um compromisso com o estado da trilha de auditoria, de modo que um avaliador posterior pode saber se o log mantido corresponde ao que foi comprometido (SECURITY_MODEL.md §6, «Retroactive modification»). O momento desse compromisso depende da confiança no operador do log ou da ancoragem; ele não mostra quando o incidente ocorreu nem que os registros são verdadeiros. partial Ancorar ou registrar no log a raiz de Merkle da auditoria com uma cadência inferior aos prazos de notificação de incidentes do art. 73 (seção 5). O serviço de ancoragem de referência ainda não envia transações on-chain (tx_hash: null); use o log de transparência ou uma ancoragem de produção contra contracts/ethereum/src/DCPAnchor.sol.

3.2 Supervisão humana

Artigo Obrigação (paráfrase) Mecanismo do DCP Cobertura O que fica para a organização
Art. 14(1)–(3) Os sistemas de risco elevado devem ser concebidos de modo que pessoas físicas possam supervisioná-los eficazmente durante o uso; as medidas são proporcionais ao risco, à autonomia e ao contexto, integradas pelo prestador ou aplicadas pelo responsável pela implantação. Controle de intenções (DCP-02): nenhuma ação sem uma Intent declarada e uma Policy Decision (approve, escalate, block); required_confirmation solicita uma Human Confirmation antes da ação. Escrutínio adaptativo: o nível de segurança (core §14, computeSecurityTier, effectiveVerificationMode) sobe com risk_score, data_classes (pii, financial_data, health_data, credentials, children_data), action_type: "initiate_payment" e estimated_impact: "high", e um verificador NÃO DEVE rebaixá-lo (core §14.3). Estados de ciclo de vida (DCP-05 §3): commissioned, active, declining, decommissioned; a especificação exige aprovação do principal para reativar a partir de declining, mas validateStateTransition só checa se a transição é uma das arestas permitidas, não a aprovação. partial Decidir quais ações são controladas e qual política produz escalate. A aplicação ou a sua integração impõe o controle sobre o que é declarado, e os verificadores checam a evidência resultante; o prestador deve fazer o sistema de IA invocar o controle. As medidas de supervisão (quem, como, com que formação) cabem ao responsável pela implantação nos termos do art. 26(2).
Art. 14(4)(a) Os supervisores devem poder entender as capacidades e limitações do sistema e monitorar seu funcionamento, incluindo a detecção de anomalias e de desempenho inesperado. Limiares de atenção (DCP-09 §4, schemas/v2/awareness_threshold.schema.json): threshold_rules[] assinadas com dimension, operator, value e action_if_triggered (notify, escalate, block); createAwarenessThreshold, evaluateSignificance, shouldNotifyHuman. Espelho do principal (DCP-09 §6, schemas/v2/principal_mirror.schema.json, generateMirror). Relatórios de vitalidade (DCP-05 §5–6, createVitalityReport) com detecção de anomalias (§6.5). Observabilidade (OBSERVABILITY.md, dcpTelemetry): latência de verificação, bundles verificados, erros e latência dos checkpoints por nível. partial As capacidades e limitações do próprio sistema de IA (exatidão, robustez, modos de falha conhecidos) vêm das instruções de utilização do prestador (art. 13). O DCP diz ao supervisor o que o agente fez e o que declarou não entender, não o que o modelo consegue fazer.
Art. 14(4)(b) Os supervisores devem estar cientes do viés de automação. Nenhum. out of scope Formação e projeto da interface. A camada narrativa dos registros de interação (linha seguinte) pode tornar o raciocínio visível, o que ajuda, mas o DCP não trata do viés de automação.
Art. 14(4)(c) Os supervisores devem poder interpretar corretamente os resultados do sistema. Registros de interação (DCP-09 §7, schemas/v2/interaction_record.schema.json): uma public_layer legível por pessoas (terms, decisions, commitments) e um private_layer_hash que se compromete com o detalhe técnico; generateInteractionRecord. DCP-09 §7.3–7.4 descrevem as camadas técnica e narrativa (o exemplo da especificação é mais rico que os campos obrigatórios do schema). Declarações de aconselhamento (DCP-09 §5, schemas/v2/advisory_declaration.schema.json): action_summary, recommended_response, significance_score. reasons da Policy Decision. partial A interpretação dos resultados do modelo (pontuações, classificações, conteúdo gerado) cabe ao prestador e ao responsável pela implantação. O DCP explica a intenção declarada do agente e seu raciocínio tal como registrado, não os resultados do modelo.
Art. 14(4)(d) Os supervisores devem poder decidir não usar o sistema ou descartar, anular ou reverter seus resultados. override_rights (booleano, obrigatório) no RPR, copiado sem alterações no RPR cego (core §12.1): o direito de anulação do principal responsável é um atributo assinado e publicado da vinculação. Human Confirmation com decision: "deny" sobre uma intenção escalada. Resposta a um aconselhamento (DCP-09 §5.5): prosseguir, anular, assumir o controle, delegar a outro lugar ou acusar recebimento, assinada pelo principal e registrada na cadeia de auditoria; advisory_declaration.human_response, response_deadline, proceeded_without_response. Regra de atenção com action_if_triggered: "block". supports Definir override_rights: true em todo agente usado em contexto de risco elevado e fazer a aplicação ou a sua integração impor um deny e um block: os verificadores não executam nenhuma das duas decisões nem confirmam que uma pessoa decidiu, e nem a verificação nem a admissão autorizam uma ação (um resultado de admissão traz action_authorized: false). Definir quem é o principal e manter as chaves dessa pessoa sob o controle dela (seção 5).
Art. 14(4)(e) Os supervisores devem poder intervir ou interromper o sistema por meio de um botão de «stop» ou similar, levando-o a um estado seguro. Revogação de emergência (core §11.3, schemas/v2/emergency_revocation.schema.json): o emergency_revocation_token registrado previamente no passaporte é SHA-256(revocation_secret); revelar o segredo revoga todas as chaves do agente sem necessidade de assinatura (generateEmergencyRevocationToken, buildEmergencyRevocation, verifyEmergencyRevocationSecret; POST /v2/emergency-revoke no serviço de revogação e no gateway, GET /v2/check/kid/:kid no serviço de revogação; a revogação assinada por kid é o POST /v2/revoke do serviço de revogação). Registro de revogação (schemas/v2/revocation_record.schema.json; o enum reason inclui key_compromise_emergency). Transição de ciclo de vida para declining ou decommissioned (DCP-05 §3.2, validateStateTransition, createDecommissioningRecord), modo termination_for_cause (§7.3). Os verificadores DEVEM invalidar os resultados em cache quando um kid signatário é revogado (core §14.5). partial A revogação interrompe a aceitação dos bundles do agente por todos os verificadores que checam revogações; ela não interrompe um processo em execução nem reverte uma ação já realizada. O comportamento em estado seguro do sistema de IA é projeto do prestador. Combine a revogação com um interruptor de desligamento no nível da aplicação e cumpra a latência de propagação da revogação do nível (SECURITY_MODEL.md, «Revocation Propagation SLAs»).
Art. 14(5) Para a identificação biométrica à distância (anexo III, ponto 1(a)): nenhuma ação com base em uma identificação sem que pelo menos duas pessoas físicas competentes a verifiquem (com exceções para aplicação da lei, migração, controle de fronteiras e asilo). Autorização multipartes (schemas/v2/multi_party_authorization.schema.json, POST /v2/multi-party/authorize do gateway; a assinatura de cada parte é verificada com suas chaves registradas e contada uma única vez). partial O DCP pode evidenciar que dois titulares de chaves distintos aprovaram uma intenção; não pode evidenciar sua competência nem que a identificação foi «verificada separadamente». A regra das duas pessoas é um processo do responsável pela implantação.
Art. 26(1)–(2) Os responsáveis pela implantação usam o sistema de acordo com as instruções de utilização e atribuem a supervisão humana a pessoas físicas com a competência, a formação, a autoridade e o apoio necessários. O RPR vincula o agente a uma pessoa física ou organização nomeada e com override_rights; o Delegation Mandate (DCP-09 §3, schemas/v2/delegation_mandate.schema.json, createDelegationMandate, verifyMandateValidity, revokeDelegation) indica o que o agente pode fazer em nome do principal (authority_scope: domain, actions_permitted, data_classes, limits; a lista de proibições do exemplo de DCP-09 §3.2 não é um campo de schema); interaction_record e DCP-09 §7.5 registram o cumprimento da delegação. partial Competência, formação e apoio são fatos organizacionais alheios ao registro. Nomeie a pessoa supervisora no RPR (entity_type: "natural_person") ou mantenha um registro interno que faça corresponder um RPR do tipo organization às pessoas atribuídas.
Art. 26(5) Os responsáveis pela implantação monitoram o funcionamento do sistema, informam o prestador nos termos do art. 72 e, se o uso puder apresentar um risco, informam o prestador ou o distribuidor e a autoridade de fiscalização do mercado e suspendem o uso; os incidentes graves são notificados primeiro ao prestador. Evidência do funcionamento: cadeia de auditoria, Policy Decisions, registros de interação, registros de obrigações com compliance_status (DCP-08 §5, recordObligation, checkRightsCompliance), relatórios de vitalidade. Suspensão: status do passaporte (suspended, declining, decommissioned), revogação, revogação de emergência. Escalonamento: DCP-08 §6.4 especifica que um descumprimento de obrigações abre uma disputa DCP-07, com os prazos de escalonamento de DCP-07 §3.2; o SDK não a abre automaticamente (reportViolation recebe um dispute_id que quem chama fornece, ou null). partial Informar o prestador, o distribuidor e a autoridade de fiscalização do mercado, e decidir que existe um risco, são atos do responsável pela implantação. O DCP não tem nenhum artefato para uma notificação a uma autoridade.

3.3 Rastreabilidade das decisões

Artigo Obrigação (paráfrase) Mecanismo do DCP Cobertura O que fica para a organização
Art. 12(2), art. 13(1) Rastreabilidade do funcionamento do sistema; um funcionamento suficientemente transparente para que o responsável pela implantação interprete os resultados e os use de forma adequada. Cadeia de decisão por ação: Intent (schemas/v2/intent.schema.json: action_type, target.channel, target.to/domain/url, data_classes, estimated_impact, requires_consent, security_tier) → Policy Decision (decision, risk_score, reasons, applied_policy_hash, resolved_tier) → Human Confirmation opcional → entrada de auditoria com outcome e evidence. O manifesto do bundle (core §9, schemas/v2/bundle_manifest.schema.json) traz rpr_hash, passport_hash, intent_hash, policy_hash e as raízes de Merkle da auditoria, e a assinatura composta do bundle cobre o manifesto. A verificação é local e reproduzível (spec/VERIFICATION.md, verifySignedBundleV2, POST /v2/bundle/verify do gateway). Os registros de interação (DCP-09 §7) acrescentam a contraparte, o mandato e a camada narrativa. supports Manter o texto ou as regras da política por trás de cada applied_policy_hash. reasons é texto livre: escreva razões que um revisor consiga ler um ano depois.
Art. 12(2)(a) Os logs devem ajudar a identificar situações que possam dar origem a um risco na acepção do art. 79(1) ou a uma modificação substancial. risk_score, resolved_tier, estimated_impact e data_classes são assinados por ação e podem ser consultados; os resultados escalated e blocked são explícitos; os limiares de atenção e as declarações de aconselhamento registram a própria incerteza do agente (significance_score; as pontuações confidence por domínio de DCP-09 §4.2–4.3 aparecem no exemplo da especificação, não em schemas/v2/awareness_threshold.schema.json). supports Definir o que conta como situação de risco para a finalidade prevista e alertar sobre ela. O DCP fornece os sinais, não a política de alertas.
Art. 86(1) Uma pessoa afetada por uma decisão tomada pelo responsável pela implantação com base nos resultados de um sistema de risco elevado do anexo III (exceto o ponto 2), com efeitos jurídicos ou efeitos adversos de importância semelhante, pode obter do responsável pela implantação explicações claras e significativas sobre o papel do sistema de IA na decisão e sobre os principais elementos da decisão. A Intent, a Policy Decision (decision, reasons, risk_score) e a Human Confirmation (quem aprovou e quando) assinadas, e a entrada de auditoria (outcome, evidence) com a qual o bundle assinado se compromete, mais o public_layer.decisions do registro de interação e o action_summary do aconselhamento, dão ao responsável pela implantação declarações assinadas do que o agente pretendia, do que a política decidiu, da confirmação registrada (a identidade real de quem confirma é estabelecida fora do DCP) e do resultado declarado. partial A explicação à pessoa afetada é um documento que o responsável pela implantação redige em linguagem clara; o DCP fornece declarações assinadas, que não provam que uma ação foi realmente executada nem estabelecem a identidade jurídica de ninguém. As decisões que não foram controladas como intenções, e o raciocínio do modelo por trás de um resultado, não estão no registro.

3.4 Explicação, reparação e disputas

Artigo Obrigação (paráfrase) Mecanismo do DCP Cobertura O que fica para a organização
Art. 27(1)(e)–(f) A avaliação de impacto sobre os direitos fundamentais (organismos públicos, prestadores de serviços públicos, anexo III, pontos 5(b) e (c)) descreve as medidas de supervisão humana aplicadas e as medidas a adotar se os riscos se materializarem, incluindo a governança interna e os mecanismos de reclamação. Medidas de supervisão concretas e documentáveis: override_rights do RPR, controle de intenções com escalate, Human Confirmations, limiares de atenção, declarações de aconselhamento, controles de ciclo de vida, revogação de emergência. Governança interna e escalonamento: o modelo de três níveis do DCP-07 (negociação direta, arbitragem contextual, recurso humano, §5) com createDispute, escalateDispute, resolveDispute, createObjection; os relatórios de violação do DCP-08 (reportViolation). partial A avaliação em si (processos, pessoas afetadas, riscos, art. 27(1)(a)–(d)) cabe ao responsável pela implantação. DCP-07 e DCP-08 são mecanismos entre os agentes e seus principais; não são um canal de reclamação para as pessoas físicas afetadas (seção 6). O Omnibus alterou o art. 27(4)–(5) para permitir referências cruzadas a uma avaliação de impacto sobre a proteção de dados do RGPD.
Art. 86 Direito a explicação (veja a linha 3.3). Recurso humano (DCP-07 §5.3): qualquer parte na disputa pode escalar aos principais responsáveis a qualquer momento; a decisão humana é definitiva dentro do protocolo e é registrada como resolução de arbitragem (schemas/v2/arbitration_resolution.schema.json). Registro de disputa (schemas/v2/dispute_record.schema.json: dispute_type, escalation_level incluindo human_appeal, status, evidence_hashes). Camada narrativa (DCP-09 §7.4): resumo em linguagem clara, decisões-chave com seu raciocínio, questões pendentes, ações para o principal. partial Esses mecanismos dão às próprias pessoas do responsável pela implantação um caminho de revisão documentado sobre as decisões do agente. O direito da pessoa afetada nos termos do art. 86 é exercido perante o responsável pela implantação, fora do protocolo.
Art. 26(11), art. 50(1) Os responsáveis pela implantação de sistemas do anexo III que tomam decisões sobre pessoas físicas, ou ajudam a tomá-las, informam essas pessoas; os prestadores garantem que as pessoas que interagem com um sistema de IA sejam informadas de que o fazem, salvo quando for evidente. O Agent Passport é uma declaração assinada e verificável de que o ator é um agente de IA vinculado a um principal nomeado, apresentável a qualquer contraparte (presentFull, presentCompact, presentReference; handshake do DCP-04 para outros agentes). partial A comunicação às pessoas físicas (interface, redação, momento «at the latest at the time of the first interaction», art. 50(5)) cabe ao prestador e ao responsável pela implantação. O DCP dá uma prova verificável que respalda a comunicação; ele não a faz.
Art. 50(2), art. 50(4) Marcação legível por máquina do conteúdo sintético; divulgação de falsificações profundas (deep fakes) e de texto gerado por IA sobre assuntos de interesse público. Nenhum. evidence.evidence_hash pode vincular os bytes declarados de um artefato; não prova que o artefato foi realmente gerado nem que foi marcado. out of scope A marcação e a detecção de conteúdo são medidas técnicas distintas.

3.5 Notificação de incidentes e acompanhamento pós-comercialização

Artigo Obrigação (paráfrase) Mecanismo do DCP Cobertura O que fica para a organização
Art. 72(1)–(2) Os prestadores estabelecem um sistema documentado de acompanhamento pós-comercialização que recolhe e analisa ativamente dados sobre o desempenho ao longo da vida útil, incluindo os dados fornecidos pelos responsáveis pela implantação e a interação com outros sistemas de IA. Dados que um responsável pela implantação pode entregar a um prestador: entradas de auditoria com resultados e evidências, Policy Decisions com risk_score, registros de obrigações (schemas/v2/obligation_record.schema.json: obligation_type, compliance_status, evidence_hashes; o compliance_history do exemplo de DCP-08 §5.2 não é um campo de schema), relatórios de vitalidade (DCP-05 §6), registros de interação com agentes contraparte (DCP-09 §7), relatórios de disputas e de violações. Cada um é assinado, ou comprometido por um bundle assinado, e o prestador pode verificá-lo sem confiar no banco de dados do responsável pela implantação. partial O sistema e o plano de acompanhamento cabem ao prestador. O Omnibus substituiu o art. 72(3): o plano continua fazendo parte da documentação do anexo IV, o ato de execução da Comissão para um modelo foi suprimido, e a Comissão deve adotar orientações, modelo incluído, até 02/09/2027 (seção 4).
Art. 73(1)–(5) Os prestadores notificam os incidentes graves (art. 3(49): morte ou dano grave à saúde, perturbação grave e irreversível de infraestruturas críticas, violação de obrigações relativas aos direitos fundamentais, dano grave à propriedade ou ao ambiente) à autoridade de fiscalização do mercado: imediatamente após estabelecer um nexo causal ou sua probabilidade razoável, e no máximo 15 dias após tomar conhecimento; 2 dias em caso de violações generalizadas ou incidentes em infraestruturas críticas; 10 dias em caso de morte. Um relatório inicial incompleto pode ser seguido de um completo. Evidência da cronologia: os carimbos de data/hora que a maioria dos artefatos assinados traz, tal como declarados por quem assina (um checkpoint PQ e uma autorização multipartes não têm nenhum, e um manifesto de bundle só uma janela de sessão assinada opcional, session_issued_at e session_expires_at); as cabeças de árvore assinadas e as provas de inclusão do log de transparência; os recibos de ancoragem. Artefatos relacionados a incidentes: revogação de emergência (qual revogação foi declarada e quando; não prova que um processo foi interrompido), termination_for_cause e sudden_failure do ciclo de vida (DCP-05 §7.3, §7.5) com a selagem da cadeia de auditoria do registro de desativação (§8.3), registros de disputa com evidence_hashes, relatórios de violação de direitos com evidence_hashes. partial Decidir que um incidente é «grave», estabelecer o nexo causal e apresentar a notificação à autoridade são atos do prestador (e, nos termos do art. 26(5), do responsável pela implantação). O DCP não tem nenhum artefato de notificação de incidente grave; rights_violation_report se refere aos direitos DCP-08 do próprio agente, e dispute_record, a conflitos entre agentes. Ancore ou registre no log com uma cadência que preserve a evidência dentro das janelas de 2, 10 e 15 dias.
Art. 73(6), primeiro parágrafo Após a notificação, o prestador investiga, realiza uma avaliação de riscos e adota medidas corretivas. Nova verificação da evidência mantida (não uma repetição da execução): verifySignedBundleV2 sobre o bundle mantido; checagens de coerência entre agentes (DCP-07 §9.2); eventos de auditoria dispute_compliance_verified / dispute_compliance_failed. partial A investigação e as medidas corretivas cabem ao prestador.

3.6 Documentação técnica

Artigo Obrigação (paráfrase) Mecanismo do DCP Cobertura O que fica para a organização
Art. 11(1), anexo IV, pontos 1(b), 2(c), 2(h), 3 Documentação técnica elaborada antes da colocação no mercado e mantida atualizada, com pelo menos os elementos do anexo IV: entre eles, como o sistema interage com outro software, incluindo outros sistemas de IA (1(b)), a arquitetura do sistema (2(c)), as medidas de cibersegurança (2(h)) e o monitoramento, o funcionamento e o controle do sistema, incluindo as medidas de supervisão humana (3). Descrições reutilizáveis e versionadas da camada de responsabilização: spec/DCP-AI-v2.0.md (normativa), spec/DCP-01.md–spec/DCP-09.md, spec/BUNDLE.md, spec/VERIFICATION.md, spec/CANONICALIZATION_PROFILE.md; os JSON Schemas de schemas/v2/; TECHNICAL_ARCHITECTURE.md (camadas, serviços, implantação); SECURITY_MODEL.md (modelo de ameaças, proteções, requisitos operacionais); NIST_CONFORMITY.md (algoritmos criptográficos); spec/AUDIT-v2.0-FINAL.md. Interoperabilidade com outros agentes: DCP-04 e a extensão do handshake de DCP-09 §8. partial O anexo IV trata do sistema de IA: finalidade prevista, desenvolvimento, dados, validação, métricas, gestão de riscos (art. 9), alterações ao longo do ciclo de vida, normas aplicadas, declaração de conformidade, plano de acompanhamento pós-comercialização. Essas seções cabem ao prestador. Os documentos do DCP podem ser citados para as partes de 1(b), 2(c), 2(h) e 3 que descrevem a camada de responsabilização, com a versão fixada (seção 5). O Omnibus alterou o art. 11(1) para estender a documentação simplificada às pequenas empresas de média capitalização.
Art. 13(3)(d), art. 13(3)(f) As instruções de utilização descrevem as medidas de supervisão humana (art. 14) e, quando aplicável, os mecanismos que permitem aos responsáveis pela implantação recolher, armazenar e interpretar os logs nos termos do art. 12. O formato do registro (schemas/v2/audit_entry.schema.json), as regras de encadeamento e de Merkle (DCP-03, core §10), a lista de verificação da verificação (spec/VERIFICATION.md), as opções de armazenamento (STORAGE_AND_ANCHORING.md) e a CLI (dcp validate-bundle, dcp merkle-root) são exatamente esse mecanismo, e os controles de supervisão da seção 3.2 são medidas descritíveis. partial Redigir as instruções de utilização. Um prestador que distribua o controle do DCP pode remeter a este documento e às especificações para o mecanismo de registro e os controles de supervisão, indicando quais estão integrados (art. 14(3)(a)) e quais o responsável pela implantação deve operar (art. 14(3)(b)).
Art. 9 Sistema de gestão de riscos: contínuo, documentado, ao longo de todo o ciclo de vida; identificação, estimativa e avaliação dos riscos; medidas; testes com métricas predefinidas. risk_score, risk_tier e o nível de segurança são sinais de controle em tempo de execução por ação, e a trilha de auditoria é uma fonte de dados para o art. 9(2)(c) (riscos que surgem dos dados pós-comercialização). Os registros de obrigações do DCP-08 trazem um compliance_status assinado e evidence_hashes; os compliance_criteria com threshold e measurement_interval que o exemplo de DCP-08 §5.2 mostra não são campos de schema. partial O sistema de gestão de riscos é um processo do prestador, não uma função do protocolo. Não apresente as pontuações de risco do DCP como a avaliação de riscos do art. 9.

3.7 Interseção com a proteção de dados

Artigo Obrigação (paráfrase) Mecanismo do DCP Cobertura O que fica para a organização
Art. 19(1), art. 26(6) (a cláusula «unless provided otherwise in ... Union law on the protection of personal data»), art. 26(9) A retenção dos logs cede diante da legislação de proteção de dados; os responsáveis pela implantação usam as informações do art. 13 para sua avaliação de impacto sobre a proteção de dados do RGPD. RPR cego (core §12.1, schemas/v2/blinded_rpr.schema.json, generatePiiSalt, blindRpr, verifyBlindedRpr; Python blind_rpr/verify_blinded_rpr, Go BlindRPR/VerifyBlindedRPR): o legal_name e o contact do RPR são substituídos por um compromisso com sal pii_hash = sha256(canonical({contact, legal_name, pii_salt})); o pii_salt (32 bytes aleatórios) é assinado com o RPR completo e quem chama deve mantê-lo privado (blindRpr o omite, mas o RPR completo o mantém); o registro cego mantém human_id, override_rights, jurisdiction, liability_mode, binding_keys e a validade. Apagar o RPR completo e seu sal torna o compromisso publicado impossível de abrir, o que a especificação oferece como apagamento para logs e âncoras imutáveis (art. 17 do RGPD); isso não comprova por si só a conformidade com o RGPD nem a anonimização, porque human_id, as demais cópias e qualquer pré-imagem vazada continuam existindo. human_id DEVE ser opaco e NÃO DEVE ser derivado de dados pessoais. As âncoras e o log de transparência guardam só hashes (STORAGE_AND_ANCHORING.md, «What goes on-chain»). supports Enviar às âncoras e aos logs de transparência só hashes, nunca um RPR, nem mesmo cego; mostrar às contrapartes externas à organização só RPRs cegos; manter toda cópia do RPR completo (e as cópias compartilhadas) sob um procedimento de apagamento; tornar human_id opaco; definir a base de retenção do RGPD para as entradas de auditoria que trazem human_id. A avaliação de impacto sobre a proteção de dados e a base jurídica cabem ao responsável pela implantação. Os compromissos pii_hash legados sem sal estão obsoletos e qualquer pessoa que adivinhe os dados pessoais pode confirmá-los (core §12.1).

4. Cronograma de aplicação

4.1 Situação do texto jurídico na data da revisão

  • Ato de base. Regulamento (UE) 2024/1689, de 13/06/2024, publicado no JO L em 12/07/2024 (EUR-Lex, CELEX 32024R1689). Art. 113: entrada em vigor no vigésimo dia seguinte ao da publicação e aplicação a partir de 02/08/2026, com as datas escalonadas abaixo.
  • Digital Omnibus on AI. A Comissão o propôs em 19/11/2025 dentro do pacote digital de simplificação. O acordo político entre o Parlamento e o Conselho foi anunciado em 07/05/2026. O ato foi adotado como Regulamento (UE) 2026/1744, de 08/07/2026, que altera os Regulamentos (UE) 2024/1689, (UE) 2018/1139 e (UE) 2023/1230; foi publicado no JO L 2026/1744 em 24/07/2026 e, nos termos de seu artigo 4, entrou em vigor no terceiro dia seguinte ao da publicação, em 27/07/2026 (EUR-Lex, ELI reg/2026/1744). O EUR-Lex o indica como «In force». A página de política sobre o Regulamento de IA da Comissão (atualizada pela última vez em 19/10/2026) e sua notícia de 27/07/2026 indicam as mesmas datas.
  • O que isso significa para este documento. Na data da revisão, o cronograma já não é uma proposta: os adiamentos são direito promulgado. Durante a fase de proposta (de novembro de 2025 a julho de 2026), as perguntas frequentes da Comissão descreviam o adiamento como «maximum 16 months later» para o anexo III e «maximum 12 months later» para o anexo I, vinculado à disponibilidade de normas e ferramentas de apoio; as datas de calendário abaixo são as promulgadas. As datas marcadas «conforme promulgado» vêm do art. 113 do ato de base; as marcadas «conforme alterado» vêm do art. 1(39)–(40) do Regulamento (UE) 2026/1744.

4.2 Datas

Data Disposição Fonte Relevância para esta correspondência
01/08/2024 Entrada em vigor do Regulamento (UE) 2024/1689 Art. 113, primeiro parágrafo (conforme promulgado) —
02/02/2025 Capítulos I e II (disposições gerais, práticas proibidas) Art. 113, terceiro parágrafo, alínea (a) (conforme promulgado; a redação alterada mantém a data e exclui as novas proibições do art. 5) Definições de prestador e de responsável pela implantação (seção 2).
02/08/2025 Capítulo III, seção 4; capítulo V (modelos de IA de finalidade geral); capítulo VII; capítulo XII e art. 78, exceto o art. 101 Art. 113, terceiro parágrafo, alínea (b) (conforme promulgado) Não coberto por este documento.
27/07/2026 Entrada em vigor do Regulamento (UE) 2026/1744; aplicam-se os artigos 102 a 110 do Regulamento de IA Art. 4 do Reg. 2026/1744; art. 113, terceiro parágrafo, nova alínea (d) (conforme alterado) —
02/08/2026 Data geral de aplicação do Regulamento de IA, incluindo o art. 50 (obrigações de transparência) e o capítulo IX (art. 72, acompanhamento pós-comercialização; art. 73, incidentes graves; art. 86, direito a explicação) Art. 113, segundo parágrafo (conforme promulgado, não alterado) Os arts. 50, 72, 73 e 86 não estão nas seções 1–3 adiadas do capítulo III. Seu alcance prático para um determinado sistema depende de sua classificação como de risco elevado, cujos requisitos substantivos se aplicam nas datas abaixo. As organizações deveriam ler o capítulo IX junto com o art. 111(2) alterado e com sua assessoria jurídica.
02/12/2026 Novas proibições do art. 5(1), primeiro parágrafo, alíneas (ba) e (bb), e art. 5(1a) e (1b); prazo para que os prestadores de sistemas de IA generativa colocados no mercado antes de 02/08/2026 cumpram a marcação do art. 50(2) Art. 113, terceiro parágrafo, alínea (a) (conforme alterado); art. 111(4) (conforme alterado) O art. 50(2) está fora do escopo do DCP (seção 3.4).
02/09/2027 Orientações da Comissão, modelo incluído, sobre o plano de acompanhamento pós-comercialização Art. 72(3) (conforme alterado) Seção 3.5.
02/12/2027 Capítulo III, seções 1, 2 e 3 (arts. 6–27, exceto o art. 6(5)) para os sistemas de IA classificados como de risco elevado nos termos do art. 6(2) e do anexo III Art. 113, terceiro parágrafo, alínea (c)(i) (conforme alterado; conforme promulgado, era 02/08/2026) Os arts. 9, 11, 12, 13, 14, 19, 26 e 27 desta correspondência se aplicam aos sistemas do anexo III a partir desta data.
02/08/2028 Capítulo III, seções 1, 2 e 3, para os sistemas de IA classificados como de risco elevado nos termos do art. 6(1) e do anexo I (componentes de segurança de produtos regulados) Art. 113, terceiro parágrafo, alínea (c)(ii) (conforme alterado; conforme promulgado, as obrigações do art. 6(1) se aplicavam a partir de 02/08/2027) Os mesmos artigos, para os sistemas do anexo I.
02/08/2030 Sistemas de IA de risco elevado destinados a ser usados por autoridades públicas e colocados no mercado ou em serviço antes da data de aplicação do capítulo III Art. 111(2) (conforme alterado) Sistemas legados de responsáveis pela implantação do setor público.

Período de transição para sistemas legados: o art. 111(2) alterado aplica o Regulamento aos sistemas de risco elevado colocados no mercado ou em serviço antes da data de aplicação do capítulo III só se sofrerem «significant changes in their designs» depois dela.

4.3 O que o Omnibus mudou e o que não mudou nos artigos desta correspondência

Verificado contra o art. 1 do Regulamento (UE) 2026/1744 em 22/10/2026:

Artigo Alterado pelo Omnibus? Efeito
Arts. 9, 12, 13, 14, 19, 26, 86 Não Conteúdo inalterado; as datas de aplicação dos arts. 9, 12, 13, 14, 19 e 26 se deslocam com o capítulo III (seção 4.2).
Art. 11(1) Sim, segundo parágrafo Documentação técnica simplificada estendida às pequenas empresas de média capitalização.
Art. 27(4)–(5) Sim A avaliação de impacto sobre os direitos fundamentais pode remeter a partes de uma avaliação de impacto sobre a proteção de dados do RGPD ou incluí-las; o modelo do Serviço para a IA deve permitir isso.
Art. 50(7) Sim A Comissão (não mais o Serviço para a IA) incentiva códigos de boas práticas sobre detecção, marcação e rotulagem de conteúdo gerado e, tendo em conta o parecer do Comitê, avalia sua adequação pelo procedimento do art. 56(6). O ato de execução que aprovava os códigos foi suprimido; mantém-se o ato de execução que estabelece regras comuns se um código for inadequado. Art. 50(1)–(6) inalterado.
Art. 72(3) Sim O modelo por ato de execução é substituído por orientações da Comissão, modelo incluído, até 02/09/2027.
Art. 73 Não diretamente O novo art. 75(1a) encaminha ao Serviço para a IA as notificações de incidentes graves dos sistemas de sua competência, aplicando-se mutatis mutandis o art. 73(2)–(9).
Art. 111 Sim O n.º 2 é substituído (período de transição, prazo de 02/08/2030 para autoridades públicas); acrescenta-se o n.º 4 (prazo de 02/12/2026 do art. 50(2) para sistemas generativos já no mercado).
Art. 113 Sim, terceiro parágrafo As alíneas (a) e (c) são substituídas e acrescenta-se a alínea (d) (seção 4.2).

Nada publicado depois de 22/10/2026 (outras alterações, atos delegados ou de execução, normas harmonizadas, orientações da Comissão nos termos do art. 72(3) ou do art. 73(7)) está refletido aqui.

5. Lista de verificação para implementadores

O que um responsável pela implantação ou um operador precisa configurar ou operar para que as linhas supports da seção 3 sejam verdadeiras em sua implantação. Os itens marcados (prestador) são para um prestador que distribui o controle do DCP dentro do sistema de IA.

5.1 Registro e retenção (arts. 12, 19, 26(6))

  • Toda ação relevante do sistema de IA é declarada como Intent e controlada por uma Policy Decision antes de ser executada; as ações que contornam o controle são listadas e justificadas nas instruções de utilização (prestador).
  • As entradas de auditoria são produzidas com a cadeia de hash duplo (hash_alg: "sha256+sha3-256", prev_hash_secondary) e com checkpoints PQ no intervalo do nível resolvido (core §14.1: a cada 50, 10 ou 1 eventos).
  • Os bundles assinados e as entradas de auditoria (não só os hashes) são gravados em armazenamento durável sob o controle da organização; o gateway, a ancoragem, o log de transparência e o serviço de revogação de referência guardam o estado em memória e não são um repositório de registros (OPERATOR_GUIDE.md, «Reference services keep state in memory only»). Defina REVOCATION_STATE_PATH para o serviço de revogação e acrescente armazenamento persistente antes de confiar nos demais.
  • É fixado para esses registros um período de retenção de pelo menos seis meses, estendido quando a finalidade prevista, a regulação setorial (por exemplo, serviços financeiros) ou um incidente em andamento exigirem, e reduzido só quando a legislação de proteção de dados exigir.
  • Os checkpoints de compactação são usados só com um arquivo dos eventos compactados durante o período de retenção.
  • O texto ou as regras da política por trás de cada applied_policy_hash estão sob controle de versões e são mantidos pelo mesmo período.
  • As chaves públicas dos agentes e o conjunto de chaves de governança são arquivados na desativação (DCP-05 §8.4) para que as assinaturas mantidas continuem verificáveis.
  • Os bundles mantidos são reverificados periodicamente com verifySignedBundleV2 (ou dcp verify-bundle) contra as chaves arquivadas e o estado de revogação, e o resultado é registrado.

5.2 Evidência de adulteração e ancoragem (art. 73(6), evidência para os arts. 72–73)

  • As raízes de Merkle da auditoria (ou os hashes dos bundles) são enviadas a um log de transparência e/ou ancoradas com uma cadência fixa. Escolha uma cadência inferior à janela de notificação de incidentes mais curta aplicável (dois dias nos termos do art. 73(3)); o típico é agrupar por hora ou por dia (TECHNICAL_ARCHITECTURE.md, camada 4).
  • O log de transparência funciona com uma OPERATOR_KEY persistente (para que as cabeças de árvore assinadas continuem sendo verificadas após reinicializações), armazenamento persistente e pelo menos um par de gossip com chave fixada (GOSSIP_PEERS).
  • As provas de inclusão e os recibos de ancoragem (anchor_receipt: cadeia, transação, bloco, ou log_url e log_index) são guardados junto aos bundles que cobrem.
  • Se for exigida ancoragem on-chain, é implantada uma ancoragem de produção contra contracts/ethereum/src/DCPAnchor.sol ou um fluxo OP_RETURN do Bitcoin; o serviço de ancoragem de referência por si só registra tx_hash: null.

5.3 Supervisão humana (arts. 14, 26(1)–(2))

  • Cada agente em contexto de risco elevado tem um RPR com override_rights: true, um expires_at vigente e binding_keys em poder do principal responsável, não do ambiente de execução do agente.
  • O principal responsável (ou as pessoas às quais corresponde um RPR do tipo organization) são as pessoas físicas atribuídas à supervisão humana nos termos do art. 26(2), e essa correspondência é mantida em um registro interno.
  • As regras da política retornam escalate com required_confirmation para os tipos de ação, classes de dados e níveis de impacto que o responsável pela implantação quer que uma pessoa aprove; a aplicação bloqueia diante de uma Human Confirmation ausente ou com deny.
  • São declarados limiares de atenção por mandato com action_if_triggered em escalate ou block para as dimensões que importam; as declarações de aconselhamento trazem um response_deadline coerente com DCP-09 §5.3, e proceeded_without_response é monitorado.
  • Existe um segredo de revogação de emergência para cada agente, em poder do principal responsável fora do ambiente de execução do agente, e a aplicação tem um interruptor de desligamento que interrompe o processo quando a revogação é acionada (a revogação por si só não interrompe um processo em execução).
  • Os verificadores checam o estado de revogação dentro da latência de propagação do nível mais alto que atendem (SECURITY_MODEL.md, «Revocation Propagation SLAs»), e o TTL do cache de verificação segue core §14.5. No @dcp-ai/sdk 2.2.1 publicado e anteriores, o VerificationCache do TypeScript é indexado só pelo hash do bundle e seu invalidateByAgent não faz nada; o código-fonte de main (não publicado) adiciona a invalidação por agente e um contexto opcional, mas nada é invalidado automaticamente. Em ambos os casos, invalide-o ou esvazie-o quando a revogação ou a confiança mudarem (API_REFERENCE.md).
  • Para a identificação biométrica à distância, a regra das duas pessoas do art. 14(5) é implementada com autorização multipartes sobre a intenção e documentada como um processo do responsável pela implantação.

5.4 Custódia de chaves e política do verificador

  • As chaves privadas são guardadas segundo os requisitos do nível de SECURITY_MODEL.md («Private Key Storage»): HSM ou TPM DEVERIA para elevated, DEVE para maximum. Este repositório não fornece integração com HSM nem TPM (o HsmCryptoProvider do código TypeScript é uma simulação); portanto, essa custódia vem da infraestrutura própria da organização.
  • A política do verificador (VerifierPolicy, VERIFIER_MODE) usa pelo menos hybrid_preferred, com risk_overrides que nunca fiquem abaixo do modo do nível; ALLOW_V1_BUNDLES=false depois de concluída a migração.
  • Os endpoints do operador estão bloqueados com OPERATOR_TOKEN; TRUST_PROXY é definido só atrás de um proxy que acrescenta o IP do cliente.
  • Os endpoints DCP-05–09 do gateway de referência, que OPERATOR_TOKEN não protege e que não verificam assinaturas, não são expostos a clientes não confiáveis (OPERATOR_GUIDE.md); os registros que eles guardam não são tratados como evidência verificada.

5.5 Proteção de dados (seção 3.7)

  • Os RPRs são criados com pii_salt; as âncoras e os logs de transparência só recebem hashes, e as contrapartes externas à organização só veem RPRs cegos.
  • human_id é um identificador opaco, não um e-mail, um nome nem o hash de nenhum deles.
  • Um procedimento de apagamento cobre toda cópia do RPR completo, incluindo as cópias compartilhadas com reguladores ou contrapartes, de modo que o apagamento do compromisso seja real.
  • A avaliação de impacto sobre a proteção de dados (e, quando o art. 27 se aplicar, a avaliação de impacto sobre os direitos fundamentais) lista os registros do DCP que contêm human_id e sua retenção.

5.6 Documentação (arts. 11, 13) — prestador

  • As instruções de utilização indicam quais medidas de supervisão estão integradas no sistema (art. 14(3)(a)) e quais o responsável pela implantação deve operar (art. 14(3)(b)), e descrevem o formato do registro e o mecanismo de verificação (art. 13(3)(f)) por referência a versões fixadas deste documento, spec/DCP-AI-v2.0.md, spec/VERIFICATION.md e schemas/v2/.
  • A documentação técnica do anexo IV cita o DCP só para a camada de responsabilização (pontos 1(b), 2(c), 2(h), 3) e nomeia a versão da especificação do DCP, as versões dos pacotes dos SDKs e a política do verificador em uso.

6. Lacunas: o que o DCP não trata

Indicadas para que ninguém cite o DCP para elas.

Área Por que o DCP não cobre
Classificação como de risco elevado, determinação do prestador e do responsável pela implantação Determinações jurídicas sobre o sistema de IA e as organizações; o DCP não conhece a finalidade prevista do sistema.
Sistema de gestão de riscos (art. 9), gestão da qualidade, avaliação da conformidade, marcação CE, registro na base de dados da UE (arts. 49, 71) Processos do prestador e atos administrativos. risk_score é um sinal de controle por ação, não uma avaliação de riscos.
Documentação técnica do sistema de IA (art. 11, anexo IV, pontos 1(a), 1(c)–(h), 2(a)–(b), 2(d)–(g), 4–9) Descreve o modelo, os dados, a validação e as alterações; o DCP documenta só a camada de responsabilização.
Instruções de utilização (art. 13(2)–(3)) Um documento do prestador. O DCP pode ser citado nele, não substituí-lo.
Viés de automação, competência e formação dos supervisores (arts. 14(4)(b), 26(2)) Fatores humanos; fora de qualquer registro que o DCP produza.
Parar o sistema de IA em um estado seguro (art. 14(4)(e)) A revogação interrompe a aceitação dos bundles do agente; não interrompe um processo nem desfaz uma ação.
Registro específico da biometria (art. 12(3)(a)–(c)) e a própria verificação por duas pessoas (art. 14(5)) O DCP não tem campos para bases de dados de referência nem entradas correspondentes, e não pode atestar a competência.
Marcação de conteúdo e divulgação de falsificações profundas (art. 50(2), 50(4)) Medidas técnicas distintas sobre o conteúdo gerado.
Comunicação às pessoas físicas (arts. 26(11), 50(1), 50(5)) A interface e a redação cabem ao prestador e ao responsável pela implantação; o DCP só fornece uma prova verificável da identidade do agente.
Notificações às autoridades de fiscalização do mercado e ao prestador (arts. 26(5), 73) O DCP não tem nenhum artefato de notificação. rights_violation_report se refere aos direitos DCP-08 do agente (integridade da memória, transição digna, coerência da identidade, registro imutável); dispute_record, a conflitos entre agentes. Nenhum dos dois é uma notificação de incidente grave.
Reclamações e explicações para as pessoas físicas afetadas (arts. 27(1)(f), 85, 86) As disputas do DCP-07 e os direitos do DCP-08 são mecanismos entre os agentes e seus principais. As pessoas afetadas não são parte no protocolo.
Plano de acompanhamento pós-comercialização (art. 72(3)) Faz parte da documentação do anexo IV do prestador; os registros do DCP são dados de entrada para ele.
Imposição da retenção Nenhum campo do DCP nem regra do verificador impõe um período de retenção; DCP-08 §3.5 enuncia o princípio e a organização o implementa. A data_disposition do registro de desativação (transferred, archived, destroyed) registra uma decisão, não a impõe. O archive_retention_period que o exemplo de DCP-05 §8.2 mostra não é um campo de schemas/v2/decommissioning_record.schema.json.
Ações fora do controle de intenções A inferência do modelo, os eventos da interface e as chamadas de ferramentas não declaradas como intenções não produzem nenhum registro do DCP.
Conteúdo dos checkpoints PQ (tag histórica v2.10.0) Na tag histórica do repositório v2.10.0, nenhum verificador de SDK checa o conteúdo dos checkpoints PQ (spec/VERIFICATION.md V2-12, OPERATOR_GUIDE.md): os checkpoints são produzidos e assinados, mas um verificador só checa a cadeia e as raízes de Merkle. Em main os verificadores dos SDKs já os checam, e segundo suas notas de publicação os pacotes atuais incluem essas verificações: npm @dcp-ai/sdk 2.2.0 e @dcp-ai/wasm 2.1.0 (npm), Python dcp-ai 2.10.0 (Python), Go v2.11.0 (Go) e Rust dcp-ai 2.11.0 (Rust). Veja também CHANGELOG.md e Versões publicadas.
Armazenamento durável nos serviços de referência O gateway, a ancoragem e o log de transparência de referência guardam o estado em memória; o serviço de revogação também, a menos que REVOCATION_STATE_PATH aponte para um armazenamento persistente (opcional). O serviço de ancoragem não envia transações on-chain.
Autenticação dos endpoints DCP-05–09 do gateway de referência Eles validam schemas, mas não verificam assinaturas nem exigem token; qualquer pessoa que consiga alcançá-los pode alterar o estado de ciclo de vida, de disputas e de mandatos (OPERATOR_GUIDE.md).

7. Fontes lidas para a revisão jurídica (22/10/2026)

Textos oficiais:

  • Regulamento (UE) 2024/1689, texto tal como publicado, HTML no EUR-Lex: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R1689 — título e cabeçalho do Jornal Oficial, os cabeçalhos das seções 1–4 do capítulo III e das seções 1–4 do capítulo IX, os artigos 3 (pontos 1, 3, 4, 12, 49), 9, 11, 12, 13, 14, 19, 26, 27, 50, 72, 73, 85, 86, 113 e o anexo IV, âncoras #art_<n> e #anx_IV.
  • Regulamento (UE) 2026/1744 (Digital Omnibus on AI): https://eur-lex.europa.eu/eli/reg/2026/1744/oj/eng — título, referência do JO, considerandos 39–41, artigo 1, pontos (10), (13), (20), (30), (31), (39), (40), artigo 4.

Páginas oficiais da Comissão:

  • Página de política sobre o Regulamento de IA: https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai (atualizada pela última vez em 19/10/2026).
  • Notícia de 07/05/2026, acordo político: https://digital-strategy.ec.europa.eu/en/news/eu-agrees-simplify-ai-rules-boost-innovation-and-ban-nudification-apps-protect-citizens
  • Notícia de 27/07/2026, entrada em vigor: https://digital-strategy.ec.europa.eu/en/news/ai-omnibus-enters-force
  • Perguntas frequentes do pacote digital (fase de proposta): https://digital-strategy.ec.europa.eu/en/faqs/digital-package (atualizada pela última vez em 20/11/2025).

Documentos do repositório em que esta correspondência se baseia: spec/DCP-AI-v2.0.md (§8–§12, §14, §18), spec/DCP-01.md–spec/DCP-03.md, spec/DCP-05.md, spec/DCP-07.md, spec/DCP-08.md, spec/DCP-09.md, spec/VERIFICATION.md, schemas/v2/*.schema.json, STORAGE_AND_ANCHORING.md, OPERATOR_GUIDE.md, SECURITY_MODEL.md, TECHNICAL_ARCHITECTURE.md, OBSERVABILITY.md, services/README.md, sdks/typescript/src/index.ts.

Este documento é informativo. Ele não altera as especificações e não é aconselhamento jurídico.