Resolução Conjunta nº 18: Transformando requisitos regulatórios em engenharia de dados

Como estruturar qualidade, rastreabilidade, governança e controles de dados em uma arquitetura Lakehouse para instituições financeiras.

Se o Banco Central pedisse hoje que sua instituição provasse que o número enviado no último SCR é o mesmo que saiu do sistema de origem, gerado por qual versão de código, validado por quais controles e aprovado por quem, quanto tempo levaria para responder? Horas, dias ou uma força-tarefa? A partir de 31 de dezembro de 2026, essa deixa de ser uma pergunta hipotética. Com a Resolução Conjunta nº 18, dado regulatório sem evidência passa a ser, na prática, dado não confiável. E a responsabilidade por isso deixa de ser da área de reporte e passa a ser do conselho de administração.

Durante anos, a qualidade das informações enviadas ao regulador foi tratada nas instituições financeiras como uma questão operacional. O arquivo precisava sair no prazo e passar no validador, e as correções eram feitas com uma remessa substituta. A engenharia por trás disso raramente era debatida no conselho de administração. Com frequência, essa engenharia era um encadeamento de extrações, planilhas de ajuste e scripts mantidos por poucas pessoas. A Resolução Conjunta nº 18, editada pelo CMN e pelo Banco Central em novembro de 2025, muda esse cenário de forma estrutural. A norma obriga instituições financeiras e demais autorizadas a funcionar pelo BCB a elaborar e implementar uma política de qualidade das informações prestadas, entrou em vigor em 1º de janeiro de 2026 e fixa 31 de dezembro de 2026 como data-limite para a adequação.

Na data desta publicação, faltam pouco mais de três meses para esse prazo. A leitura mais comum da norma é jurídica e de governança: redigir a política, nomear o diretor responsável e aprovar no conselho. Esses passos são necessários, mas não bastam. O texto exige de forma explícita arquitetura de dados, validação automatizada, reconciliações, rastreabilidade de ponta a ponta e trilhas de auditoria. Isso é engenharia de dados. Este artigo propõe uma leitura técnica da resolução. O objetivo é mostrar, com modelagens e exemplos concretos, como uma plataforma Lakehouse com arquitetura medalhão atende aos requisitos da norma e ainda produz a evidência de que eles foram cumpridos.

O que a Resolução Conjunta nº 18 exige de fato

A norma é curta e densa. Antes de desenhar qualquer arquitetura, vale decompor o que ela pede, porque cada dispositivo gera uma demanda técnica diferente.

Escopo. A política abrange dados quantitativos e qualitativos, documentos e relatórios remetidos ou disponibilizados ao BCB, seja por exigência legal, regulamentar ou por demanda específica da autarquia, e deve ser proporcional à natureza, porte, complexidade, perfil de risco e modelo de negócio da instituição. Não se trata apenas dos documentos periódicos, como o SCR (Doc. 3040) ou o balancete (Doc. 4010). Entram também as respostas a ofícios e as demandas pontuais da supervisão.

Definição de qualidade. A qualidade é definida como a adequação das informações às condições das leis, regulamentos ou demandas do BCB, observadas doze dimensões: acessibilidade, acurácia, adaptabilidade, clareza, comparabilidade, completude, confiabilidade, consistência, integridade, rastreabilidade, relevância e tempestividade.

Características mínimas da política (art. 3º). Aqui está o núcleo técnico. A política deve contar com arquitetura de dados e infraestrutura de TI capazes de cumprir as exigências de reporte inclusive em situações adversas ou de crise, com instrumentos de validação prévia, detecção e resolução tempestiva de erros desde a preparação até a apresentação, e com ferramentas e técnicas de gestão da informação automatizadas e integradas. Ela também deve documentar as etapas de preparação, verificação e fornecimento, com ordem cronológica, áreas responsáveis, dicionário de dados e garantia de que as informações sejam auditáveis, com trilhas de verificação. No campo do monitoramento, a norma pede testes de qualidade antes do envio, incluindo os definidos pelo próprio BCB, com revisões e reconciliações entre o que é reportado e os sistemas internos, além de um relatório semestral consolidado com as irregularidades encontradas e as medidas saneadoras adotadas e em curso.

Tratamento de falhas. Os diretores das áreas produtoras devem definir prazos para sanar irregularidades. Se o prazo não for cumprido, um plano de ação vai ao conselho de administração ou, na falta dele, à diretoria. A instituição deve ainda comunicar ao BCB as impropriedades não corrigidas até o dia do envio, com abrangência, relevância e previsão de solução, junto com as providências contra reincidência e os planos de ação.

Responsabilidade da alta administração. O conselho aprova e revisa a política no mínimo anualmente, define diretrizes, provê recursos e dissemina a cultura de qualidade. A diretoria garante o atendimento às dimensões e a realização de testes específicos. É obrigatório designar um diretor responsável perante o BCB, e essas atribuições não podem ser delegadas.

Poderes do regulador e retenção. O BCB pode estabelecer testes específicos e níveis mínimos de qualidade para aceitação, rejeitar remessas, determinar a substituição de informações e exigir novas divulgações ao público ou a terceiros. A documentação da política e os relatórios semestrais devem ficar disponíveis por pelo menos cinco anos. A norma também revoga dispositivos da Resolução CMN nº 4.968/2021, que trata de controles internos.

Um ponto merece destaque. O BCB se reserva o direito de publicar testes e patamares mínimos de aceitação. Por isso, a plataforma não pode tratar regras de qualidade como código espalhado em pipelines. Elas precisam ser um ativo gerenciável, capaz de receber regras externas sem reescrever a arquitetura.

Por que este é um problema de arquitetura, e não apenas de política

Quem já acompanhou um ciclo de envio regulatório conhece o padrão. Os dados saem de sistemas transacionais heterogêneos, passam por extrações noturnas e ganham ajustes manuais em planilhas "temporárias" que duram anos. Depois são montados em arquivos XML ou TXT por rotinas cuja lógica ninguém documenta por completo. Nesse modelo, cada dimensão da norma esbarra em uma limitação física. A rastreabilidade se perde na planilha. A integridade depende de quem teve acesso à pasta de rede. A confiabilidade não pode ser medida, porque ninguém guarda o valor originalmente enviado de forma estruturada.

A triggo.ai recomenda tratar a resolução como um programa estruturante de qualidade e governança da informação, e não como um ajuste pontual de reporte, conectando dimensões de qualidade a processos, controles, dados e TI.

É exatamente nessa lacuna, entre o documento aprovado e a operação que funciona todo mês, que a arquitetura de dados decide o resultado. Um Lakehouse com arquitetura medalhão oferece três propriedades estruturais alinhadas à norma. A primeira é a separação clara entre dado bruto imutável e dado transformado, o que dá integridade e rastreabilidade. A segunda é que cada camada representa um estágio verificável do ciclo de vida, o que dá validação desde a preparação até a apresentação. A terceira é que controles, metadados e evidências são tratados como dados de primeira classe, o que permite monitoramento contínuo e relatório semestral gerado a partir da própria plataforma.

Das 12 dimensões aos controles técnicos: um mapa de tradução

O passo mais didático, e o mais útil para alinhar áreas de negócio, compliance e engenharia, é traduzir cada dimensão em um controle concreto, com a camada em que ele atua e uma métrica que permita monitorá-lo. A tabela abaixo serve como ponto de partida e deve ser adaptada ao porte e à complexidade de cada instituição, como a própria norma exige.

Dois pontos dessa tabela costumam surpreender. O primeiro é a confiabilidade. A norma a define como ausência de desvio relevante entre o dado revisado e o valor inicial. Portanto, ela só pode ser medida se a plataforma guardar o valor inicial. Isso muda a modelagem da camada Gold, como se verá adiante. O segundo é a adaptabilidade. Ela exige gerar informações não periódicas, inclusive em crise, o que penaliza arquiteturas que constroem cada documento regulatório diretamente das fontes, sem um modelo intermediário reutilizável.

Arquitetura de referência: medalhão com plano de controle

A proposta combina as três camadas clássicas com uma camada Gold dedicada ao reporte regulatório e um plano de controle transversal, onde vivem as regras, os metadados e as evidências.

A lógica é simples. Os dados fluem da esquerda para a direita. Os metadados e as evidências fluem de todas as camadas para baixo, para o plano de controle. É desse plano que saem o dicionário de dados, as trilhas de auditoria, os indicadores de qualidade e, por fim, o relatório semestral. As próximas seções detalham cada camada.

Bronze: integridade e rastreabilidade começam na ingestão

A camada Bronze tem uma missão regulatória precisa: provar que o dado recebido é autêntico e não foi alterado. Isso atende diretamente às dimensões de integridade e rastreabilidade. Três princípios orientam o desenho. O primeiro é a imutabilidade: a Bronze é append-only e correções nunca sobrescrevem o recebido. O segundo são os metadados de proveniência em cada registro. O terceiro são hashes que permitem verificar, a qualquer momento, se o conteúdo foi adulterado.

-- Bronze: registro original + metadados de proveniência e integridade

CREATE TABLE bronze.core_credito_operacoes_raw (

 payload VARIANT, -- registro original, sem transformação

 _source_system VARCHAR, -- ex.: 'CORE_CREDITO'

 _source_file VARCHAR, -- arquivo ou tópico de origem

 _file_sha256 VARCHAR, -- integridade do artefato recebido

 _record_hash VARCHAR, -- SHA2(TO_JSON(payload), 256)

 _batch_id VARCHAR, -- lote de ingestão

 _ingested_at TIMESTAMP_TZ DEFAULT CURRENT_TIMESTAMP()
);

Na ingestão, também é recomendável registrar uma contagem de controle por lote, informando quantos registros a fonte declarou ter enviado e quantos foram efetivamente carregados. Essa é a forma mais barata e eficaz de medir completude na origem, e ela pega o erro mais comum e mais silencioso: o arquivo truncado.

Há uma nuance técnica importante. Recursos como o Time Travel do Snowflake ou o histórico de versões do Delta Lake ajudam na auditoria de curto prazo, mas têm janelas de retenção limitadas. A norma pede que documentação e relatórios fiquem disponíveis por cinco anos. Como boa prática, a trilha de verificação dos dados efetivamente reportados deve ser preservada por um mecanismo explícito, com snapshots e manifestos, e não depender da retenção nativa do formato de tabela.

Silver: data contracts, regras de qualidade e quarentena

A Silver é onde o dado ganha significado de negócio. Chaves são conformadas, domínios são padronizados (modalidades de crédito, contas COSIF, códigos de garantia) e o modelo canônico é construído no grão mais fino possível. É esse grão fino que sustenta a adaptabilidade: quando o BCB faz uma demanda ad hoc, a resposta sai de agregações sobre a Silver, e não de uma nova extração das fontes.

É também a camada natural para a maior parte das regras de qualidade. Um padrão que funciona bem é associar cada teste à dimensão da RC 18 que ele protege, usando metadados. Isso permite consolidar os resultados por dimensão no relatório semestral sem trabalho manual. Um exemplo com dbt:

models:
  - name: slv_operacao_credito
    description: "Operações de crédito conformadas. Grão: 1 linha por contrato por data-base."
    config:
      contract: {enforced: true}
      meta: { owner: "diretoria_credito", documentos_regulatorios: ["3040"]}
    columns:
      - name: id_contrato
        data_type: varchar
        data_tests:
          - not_null:
              config: { severity: error, meta: { dimensao_rc18: completude}}
      - name: data_base
        data_type: date
      - name: cpf_cnpj_cliente
        data_type: varchar
        data_tests:
          - not_null:
              config: { severity: error, meta: { dimensao_rc18: completude}}
      - name: cod_modalidade
        data_type: varchar
        data_tests:
          - relationships:
              to: ref('ref_modalidade_scr')
              field: cod_modalidade
              config: { severity: error, meta: { dimensao_rc18: consistencia}}
      - name: saldo_devedor
        data_type: number(18,2)
        data_tests:
          - dbt_utils.accepted_range:
              min_value: 0
              config: { severity: error, meta: { dimensao_rc18: acuracia}}
    data_tests:
      - dbt_utils.unique_combination_of_columns:
          combination_of_columns: [id_contrato, data_base]
          config: { meta: { dimensao_rc18: consistencia}}

O contract: enforced funciona como um data contract. Se uma mudança no sistema de origem alterar o tipo ou remover uma coluna, a carga falha antes de propagar o problema. É a "validação prévia" do art. 3º aplicada ao esquema, e não apenas ao conteúdo.

Registros que violam regras não devem simplesmente desaparecer, pois isso comprometeria a completude sem deixar rastro. O padrão recomendado é a quarentena: o registro inválido é segregado com o motivo da rejeição, vira um item de trabalho para o data steward e entra nas métricas de qualidade.

-- Quarentena: registros inválidos segregados com motivo e dimensão afetada

CREATE OR REPLACE TABLE silver.slv_operacao_credito_quarentena AS

WITH avaliado AS (

 SELECT s.*,

 ARRAY_CONSTRUCT_COMPACT(

 IFF(s.cpf_cnpj_cliente IS NULL, 'COMPLETUDE:cpf_cnpj_nulo', NULL),

 IFF(s.saldo_devedor < 0, 'ACURACIA:saldo_negativo', NULL),

 IFF(m.cod_modalidade IS NULL, 'CONSISTENCIA:modalidade_invalida', NULL)

 ) AS motivos

 FROM staging.stg_operacao_credito s

 LEFT JOIN silver.ref_modalidade_scr m

 ON s.cod_modalidade = m.cod_modalidade
)
SELECT * FROM avaliado
WHERE ARRAY_SIZE(motivos) > 0;

Na prática, as plataformas oferecem mecanismos nativos que complementam esse padrão. No Snowflake, as Data Metric Functions permitem anexar métricas como contagem de nulos ou de duplicados diretamente às tabelas, com execução agendada ou disparada por alteração. No Databricks, as expectations dos pipelines declarativos permitem descartar, reter ou falhar registros conforme a regra. A escolha da ferramenta importa menos do que o princípio: toda regra tem identificador, dimensão, severidade e owner, e todo resultado é persistido.

Um alerta vale para a Silver: os ajustes manuais. Toda instituição tem reclassificações e correções que analistas aplicam antes do envio. Proibi-los é irreal. Mantê-los em planilhas é incompatível com a rastreabilidade exigida. A saída é tratá-los como dado governado, em uma tabela de ajustes com justificativa, autor, aprovador e vigência, que entra no pipeline como qualquer outra fonte e aparece na linhagem.

Gold regulatória: modelagem bitemporal para confiabilidade e comparabilidade

A camada Gold regulatória contém um mart por documento, no formato mais próximo possível do leiaute exigido. Sua característica decisiva é a modelagem bitemporal. Cada registro carrega dois tempos. A data-base é o momento do fato ao qual a informação se refere. A versão da remessa e a data de geração indicam o momento em que a instituição produziu aquela visão.

-- Gold regulatória: cada remessa é preservada; substituições geram nova versão

CREATE TABLE gold_reg.scr3040_operacao (

 data_base DATE, -- tempo do fato (mês de referência)

 versao_remessa INTEGER, -- 1 = envio original; 2+ = substituições

 dt_geracao TIMESTAMP_TZ, -- tempo de processamento

 id_contrato VARCHAR,

 cpf_cnpj_cliente VARCHAR,

 cod_modalidade VARCHAR,

 natureza VARCHAR,

 saldo_devedor NUMBER(18, 2),

 _run_id VARCHAR, -- execução do orquestrador que gerou a versão

 _git_sha VARCHAR, -- versão exata do código de transformação

 PRIMARY KEY (data_base, versao_remessa, id_contrato)
);

Por que isso importa? Um exemplo ajuda. Suponha que a remessa do SCR com data-base de junho foi enviada e, em agosto, identificou-se uma falha na classificação de modalidade de um lote de contratos, o que exigiu substituição. Em uma arquitetura que sobrescreve a tabela, a informação original deixa de existir e a instituição não consegue responder quanto o dado mudou. Com a modelagem bitemporal, a medição de confiabilidade, tal como definida pela norma, vira uma consulta simples:

-- Confiabilidade: desvio entre o valor originalmente reportado e a última versão

WITH totais AS (

 SELECT data_base, versao_remessa, SUM(saldo_devedor) AS saldo

 FROM gold_reg.scr3040_operacao

 GROUP BY data_base, versao_remessa
),
ultima AS (

 SELECT data_base, MAX(versao_remessa) AS versao_final

 FROM totais GROUP BY data_base

)

SELECT o.data_base,

 o.saldo AS saldo_original,

 f.saldo AS saldo_versao_final,

 (f.saldo - o.saldo) / NULLIF(o.saldo, 0) AS desvio_revisao_pct

FROM totais o

JOIN ultima u ON u.data_base = o.data_base

JOIN totais f ON f.data_base = u.data_base AND f.versao_remessa = u.versao_final

WHERE o.versao_remessa = 1;

A mesma estrutura sustenta a comparabilidade. Quando uma metodologia muda, por exemplo uma nova regra de alocação entre modalidades, a mudança fica registrada na versão de código (_git_sha) e na nota metodológica do catálogo. Assim, é possível explicar qualquer quebra de série. O mesmo raciocínio vale para dimensões com hierarquia, como plano de contas e estrutura organizacional, que devem ser modeladas como SCD Tipo 2 na Silver para que um período antigo seja sempre reconstruído com a hierarquia vigente à época.

Reconciliações: consistência entre o que se reporta e o que se contabiliza

A norma cita de forma expressa as reconciliações entre os dados reportados e os sistemas internos. Na prática, a reconciliação mais emblemática em instituições de crédito é o confronto entre a carteira informada no SCR e o saldo contábil das operações de crédito no balancete. As duas visões nunca batem ao centavo, por diferenças conceituais legítimas como rendas a apropriar e itens de naturezas distintas. Por isso, o controle maduro não exige igualdade. Ele exige que toda diferença seja explicada, e só a diferença não explicada é tratada como falha.

-- Reconciliação SCR (3040) x contábil (4010), com itens de conciliação explicados

WITH scr AS (

 SELECT data_base, SUM(saldo_devedor) AS vl_scr

 FROM gold_reg.scr3040_operacao

 WHERE versao_remessa = 1

 AND natureza = 'CARTEIRA_CLASSIFICADA' -- recorte ilustrativo

 GROUP BY data_base

),

contabil AS (

 SELECT data_base, SUM(saldo) AS vl_cosif

 FROM gold_reg.cadoc4010_balancete

 WHERE conta_cosif LIKE '16%' -- grupo Operações de Crédito

 GROUP BY data_base

),

explicados AS (

 SELECT data_base, SUM(valor) AS vl_explicado

 FROM silver.conciliacao_itens_explicados -- itens com justificativa e aprovação

 WHERE id_reconciliacao = 'REC-SCR-COSIF-16'

 GROUP BY data_base

)

SELECT s.data_base, s.vl_scr, c.vl_cosif,

 COALESCE(e.vl_explicado, 0) AS vl_explicado,

 s.vl_scr - c.vl_cosif - COALESCE(e.vl_explicado, 0) AS dif_nao_explicada,

 ABS(s.vl_scr - c.vl_cosif - COALESCE(e.vl_explicado, 0))

 / NULLIF(c.vl_cosif, 0) <= 0.001 AS dentro_tolerancia

FROM scr s

JOIN contabil c ON c.data_base = s.data_base

LEFT JOIN explicados e ON e.data_base = s.data_base;

O resultado dessa consulta não termina em um dashboard. Ele é persistido como execução de controle, alimenta o quality gate e, se falhar, abre um incidente. A tabela de itens explicados, com justificativa e aprovador, é ela própria uma evidência. Ela mostra ao auditor que a diferença foi analisada, e não ignorada.

Uma boa carteira de reconciliações costuma combinar três tipos. O primeiro são as reconciliações verticais, da fonte para a Bronze, a Silver e a Gold, que provam que nada se perdeu no caminho. O segundo são as reconciliações horizontais, entre documentos regulatórios diferentes que descrevem o mesmo fato. O terceiro são as reconciliações contábeis, entre o reportado e o razão. A norma não fixa a quantidade. O princípio da proporcionalidade sugere priorizar os documentos de maior materialidade e maior histórico de apontamentos.

Rastreabilidade e auditabilidade: o manifesto de remessa

A norma exige rastrear a informação da origem ao usuário final e garantir trilhas de verificação. Linhagem colunar automática, disponível no Unity Catalog, no Snowflake Horizon ou via padrões abertos como o OpenLineage, resolve a parte estrutural: de qual coluna de qual tabela veio cada campo. Falta a parte transacional: o que exatamente foi enviado em cada remessa, gerado por qual código, a partir de quais lotes e aprovado por quem.

A peça que fecha essa lacuna é o manifesto de remessa. Trata-se de um registro imutável, gravado em um evidence store com retenção longa, que acompanha cada envio:

{
  "documento": "3040",
  "data_base": "2026-08-31",
  "versao_remessa": 1,
  "arquivo_sha256": "9f2c4e…",
  "git_sha": "a41e7d2",
  "run_id": "scr3040__2026-09-05T02:00",
  "lotes_origem": ["CORE_CREDITO@8812", "GARANTIAS@1204"],
  "testes": {"executados": 412, "falhas_bloqueantes": 0, "falhas_nao_bloqueantes": 3},
  "reconciliacoes": [
    {"id": "REC-SCR-COSIF-16", "status": "OK", "dif_nao_explicada_pct": 0.0004}
  ],
  "pendencias_comunicadas_bcb": ["DQ-SCR-117"],
  "aprovacoes": [
    {"papel": "owner_documento", "usuario": "…", "ts": "2026-09-05T09:12:00-03:00"}
  ]
}

Com o manifesto, uma pergunta de auditoria como "prove que o arquivo enviado em setembro é o mesmo gerado pelo pipeline, com quais controles e sob qual aprovação" deixa de exigir uma força-tarefa. Ela vira uma consulta. O hash do arquivo prova a integridade. O git_sha permite reconstruir a lógica exata. Os lotes de origem ligam a remessa à Bronze, e dali à fonte.

O quality gate: validação prévia como etapa obrigatória do pipeline

O art. 3º pede testes antes do fornecimento das informações. O art. 9º pede que impropriedades não corrigidas até o envio sejam comunicadas ao BCB. Juntos, esses dispositivos descrevem um quality gate: uma etapa do orquestrador que decide se a remessa pode seguir e, se seguir com pendências, registra a comunicação correspondente.

def quality_gate(documento: str, data_base: date) -> GateResult:
    # Regras internas + testes definidos pelo BCB, lidas do catálogo de regras
    resultados = executar_testes(documento, data_base)
    reconciliacoes = executar_reconciliacoes(documento, data_base)

    manifesto = gerar_manifesto(documento, data_base, resultados, reconciliacoes)
    evidence_store.gravar(manifesto)  # imutável, retenção mínima de 5 anos

    bloqueantes = [r for r in resultados + reconciliacoes
                   if not r.passou and r.severidade == "BLOQUEANTE"]
    if bloqueantes:
        abrir_incidentes(bloqueantes, owner=owner_do_documento(documento))
        return GateResult(liberado=False, motivos=bloqueantes)

    pendencias = [r for r in resultados + reconciliacoes if not r.passou]
    if pendencias:
        # Art. 9º: abrangência, relevância e prazo previsto de solução
        registrar_comunicacao_bcb(documento, data_base, pendencias)
        abrir_incidentes(pendencias, owner=owner_do_documento(documento))

    return GateResult(liberado=True, aprovador=owner_do_documento(documento))

Três decisões de desenho merecem atenção. Primeiro, as regras são lidas de um catálogo, e não codificadas no gate. Quando o BCB publicar testes específicos ou níveis mínimos de aceitação, como o art. 10 prevê, a instituição cadastra novas regras sem alterar o pipeline. Segundo, a severidade é explícita. Nem toda falha deve bloquear o envio, porque perder o prazo também viola a tempestividade. Mas toda falha não bloqueante precisa virar comunicação e incidente. Terceiro, a aprovação humana continua existindo, agora apoiada em evidência. O owner do documento aprova com base no resultado dos controles, e não em uma conferência visual do arquivo.

Monitoramento contínuo e o relatório semestral gerado a partir dos dados

Se todos os testes, reconciliações e incidentes são persistidos, o relatório semestral exigido pela norma deixa de ser um documento redigido às pressas. Ele passa a ser um produto de dados. O modelo mínimo tem três entidades:

• dim_regra_qualidade: identificador, descrição, dimensão da RC 18, documento, severidade, owner e origem (interna, BCB ou auditoria).
• fato_execucao_controle: cada execução de teste ou reconciliação, com data-base, run, registros avaliados, registros com falha e resultado.
• fato_incidente_qualidade: cada irregularidade, com origem (monitoramento, apontamento do BCB ou auditoria), data de abertura, prazo definido pelo diretor responsável, status, indicador de escalonamento ao conselho, data de resolução e flag de reincidência.

A partir desse modelo, o núcleo do relatório sai de consultas como esta:

-- Desempenho por dimensão da RC 18 no semestre

SELECT r.dimensao_rc18,

 COUNT(*) AS execucoes,

 AVG(IFF(e.passou, 1, 0)) AS taxa_aprovacao,

 SUM(e.registros_falha) AS registros_com_falha

FROM controle.fato_execucao_controle e

JOIN controle.dim_regra_qualidade r ON r.id_regra = e.id_regra

WHERE e.data_base BETWEEN '2026-07-01' AND '2026-12-31'

GROUP BY r.dimensao_rc18

ORDER BY taxa_aprovacao;

Consultas análogas sobre a tabela de incidentes respondem aos demais pontos exigidos: irregularidades encontradas (inclusive as apontadas pelo BCB), medidas adotadas e em curso, incidentes que estouraram o prazo e foram escalados ao conselho, e taxa de reincidência. Esta última mede se as "providências para mitigar a reincidência" do art. 9º funcionam de fato. O relatório pode então ser submetido ao conselho, ao comitê de auditoria e às auditorias interna e independente, e remetido ao BCB quando requerido, sempre com a mesma base de números.

Tempestividade e adaptabilidade: projetando para o pior dia

Duas dimensões dependem mais de engenharia de plataforma do que de regras de dados. A tempestividade exige que cada documento tenha um SLA explícito no orquestrador, com uma folga calculada entre o fim do processamento e o prazo regulatório. Também exige alertas de freshness nas fontes críticas, porque a causa mais comum de atraso não é o pipeline regulatório, e sim uma fonte que não chegou.

A adaptabilidade tem um componente que a norma enfatiza duas vezes: situações adversas ou de crise. Em um evento de estresse de liquidez, o regulador tende a pedir informações fora do calendário, em recortes inéditos e com prazos curtos. Instituições que só conseguem produzir os leiautes pré-definidos ficam expostas. A combinação de um modelo canônico granular na Silver com uma camada semântica de métricas governadas permite responder com consistência, porque as métricas usadas na demanda ad hoc são as mesmas que alimentam os documentos periódicos. Planos de continuidade, com recuperação de desastre, runbooks e testes periódicos de reprocessamento de uma data-base completa, completam essa dimensão.

Governança: o modelo de responsabilidades que a norma exige

A tecnologia sustenta a política, mas a norma é clara ao atribuir responsabilidades que não podem ser delegadas. Uma matriz de papéis compatível com o texto costuma ter este desenho:

O dicionário de dados exigido pelo art. 3º merece uma recomendação específica: tratá-lo como código. Descrições, tipos, formatos e vínculos regulatórios ficam versionados junto aos modelos e são publicados automaticamente no catálogo. Assim, o dicionário nunca diverge do que está em produção, que é a falha mais frequente dos dicionários mantidos em documentos à parte.

Desafios e armadilhas mais comuns

Algumas armadilhas aparecem com frequência em programas desse tipo. A primeira é tratar a norma como projeto de compliance puro: a política é redigida sem que a arquitetura consiga produzir as evidências que ela promete, e a lacuna aparece na primeira avaliação da auditoria interna. A segunda é controlar só o arquivo final. Validar o leiaute na saída é necessário, mas a norma pede detecção desde a preparação dos dados, e erros detectados só no fim custam mais tempo, justamente quando o prazo aperta. A terceira é ignorar a confiabilidade: sem snapshots versionados, a instituição não consegue medir uma das doze dimensões e só descobre isso quando precisa reportar o indicador. A quarta é subestimar a computação de usuário final. Planilhas e macros no caminho do reporte são, na maioria das instituições, o maior gap de rastreabilidade e integridade, e costumam ficar fora do inventário inicial. A última é superdimensionar o programa. A norma exige proporcionalidade, e uma instituição de pequeno porte não precisa da mesma cobertura de um conglomerado prudencial S1. Precisa de coerência entre porte, risco e controles.

Como a inteligência artificial pode apoiar a gestão da qualidade

A Resolução Conjunta nº 18/2025 não exige o uso de inteligência artificial (IA). Ainda assim, algumas aplicações podem ajudar as instituições a estruturar e executar processos relacionados à qualidade das informações, desde que sejam compatíveis com suas políticas de governança, segurança e controle.

Na etapa de preparação e verificação, ferramentas de IA podem apoiar a identificação de anomalias, padrões incomuns e divergências entre bases e relatórios. Também podem auxiliar na classificação de inconsistências, na priorização de exceções e na busca por possíveis causas-raiz. Esses usos podem contribuir para controles associados à acurácia, consistência, completude e tempestividade — mas seus resultados precisam ser verificados antes de fundamentar decisões ou correções.

A IA também pode apoiar a documentação e a rastreabilidade. Por exemplo, pode ajudar a organizar metadados, sugerir relações entre conjuntos de dados e resumir regras ou etapas de processamento já registradas. Em processos com documentos e informações textuais, técnicas de IA podem facilitar a extração de campos e a comparação entre versões. Essas possibilidades não substituem a manutenção de registros confiáveis sobre a origem dos dados, as transformações realizadas, os responsáveis e as validações aplicadas.

Há, porém, limites importantes. Sistemas de IA podem produzir resultados incorretos, inconsistentes ou difíceis de explicar; modelos também podem apresentar mudanças de desempenho ao longo do tempo. Por isso, seu uso deve prever validação, monitoramento, controle de acesso, registro das operações e revisão humana proporcional ao risco. Informações confidenciais ou dados pessoais também exigem cuidados específicos de proteção e uso.

A contribuição mais adequada da IA, nesse contexto, é ampliar a capacidade de detectar e investigar problemas, não assumir a responsabilidade pela qualidade das informações. A instituição continua responsável por definir controles, avaliar os resultados e corrigir eventuais falhas; e a administração mantém as responsabilidades estabelecidas pela resolução. Assim, a IA pode fortalecer os processos de qualidade quando integrada a uma governança clara, com evidências verificáveis e supervisão humana.

Conclusão: qualidade de dados como capacidade institucional

A Resolução Conjunta nº 18 formaliza algo que as boas práticas internacionais, como os princípios BCBS 239 de agregação de dados de risco, já indicavam há mais de uma década: a qualidade da informação regulatória é responsabilidade da alta administração e depende de arquitetura, e não de esforço heroico a cada fechamento. O mérito da norma está em tornar essa responsabilidade verificável. O regulador pode rejeitar remessas, exigir substituições e republicações e questionar a própria política.

A arquitetura medalhão, acrescida de um plano de controle, oferece um caminho concreto para responder a essa exigência. A Bronze prova a integridade. A Silver concentra as regras e os contratos de dados. A Gold bitemporal preserva o que foi reportado e mede a confiabilidade. O quality gate e o manifesto transformam cada remessa em evidência auditável, e o relatório semestral passa a ser uma consequência dos dados, e não um documento produzido à parte. Instituições que fizerem esse movimento não apenas cumprirão a norma. Elas ganharão uma base de dados confiável que também serve à gestão de riscos, à contabilidade e às iniciativas de analytics e IA.

Este conteúdo tem caráter técnico e informativo e não substitui a análise jurídica e regulatória específica de cada instituição.

Adequação à RC 18 com quem entende de dados e de plataforma

A triggo.ai apoia instituições financeiras em toda a jornada de adequação à Resolução Conjunta nº 18: do diagnóstico de aderência e do mapeamento de dados críticos ao desenho e à implementação da arquitetura medalhão com plano de controle, incluindo regras de qualidade, reconciliações, linhagem, quality gates e o relatório semestral gerado a partir dos dados.

Se a sua instituição precisa chegar a 31 de dezembro com uma política sustentada por evidência e sair dela com uma plataforma pronta para crescer, fale com os especialistas da triggo.ai e agende uma avaliação de prontidão para a RC 18.