MARCA CHECAR: A VERIFICAÇÃO COMO FRONTEIRA DA ENGENHARIA DE SISTEMAS ASSISTIDA POR IA

“Deu a ordem? Recebeu o ‘pronto’? Marca checar. A IA mudou o executor; não aboliu a responsabilidade de verificar.”

— Cleomar Marques, Ph.D.

1. Introdução

A popularização dos modelos generativos permitiu solicitar programas em PHP, Java, Rust e outras linguagens sem que o solicitante necessariamente domine a sintaxe empregada. Um sistema pode entregar rapidamente scripts executáveis, rotinas de integração, páginas web e até conjuntos de testes. Isso representa um avanço real na produtividade. Não significa, porém, que o produto gerado esteja apto a operar em qualquer ambiente.

Em artigo anterior, discutiu-se que “quanto mais poderosa a IA, menos bastará saber pedir — será preciso saber especificar” [1]. O passo seguinte consiste em examinar uma pergunta complementar e mais exigente: quem tem competência para conferir aquilo que a IA entregou?

Na experiência profissional de comando e controle, especialmente em organizações que dependem de execução disciplinada de ordens, receber a comunicação de que determinada atividade foi concluída não encerra o processo de supervisão. A expressão “marca checar”, empregada na Marinha, sintetiza a necessidade de verificar a execução. Uma ordem pode ter sido compreendida parcialmente, interpretada de forma distinta ou cumprida sem atender integralmente à finalidade pretendida. O “pronto” informa uma conclusão declarada; não demonstra, por si só, a conformidade do resultado.

Com a IA, o agente executor muda, mas o problema permanece. Uma resposta fluente, uma tela visualmente consistente ou um script que executa sem erros são evidências insuficientes de correção. A Engenharia precisa converter declarações de êxito em evidências verificáveis de atendimento aos requisitos.

2. Desenvolvimento

Parte I — Da ordem à evidência: o princípio “marca checar”

Em uma operação, convém distinguir seis estados: (i) intenção e objetivo; (ii) ordem ou requisito transmitido; (iii) interpretação pelo executor; (iv) execução; (v) comunicação de conclusão; e (vi) verificação e aceite. As etapas não são equivalentes. O fato de o executor informar o cumprimento da tarefa não permite deduzir que o objetivo foi alcançado.

Transpondo essa estrutura para sistemas gerados por IA, o pedido em linguagem natural corresponde à transmissão de uma intenção. A resposta do modelo pode apresentar código e indicar que a tarefa foi concluída. Todavia, a confirmação precisa ser confrontada com requisitos aprovados, restrições operacionais, critérios de aceite e evidências colhidas em ambiente apropriado.

Há pelo menos três planos independentes de análise:

• Correção sintática: o código é válido para a linguagem e pode ser processado por interpretador, compilador ou ferramentas correlatas?
• Adequação semântica: o comportamento implementado corresponde ao problema efetivo, inclusive regras de negócio, exceções e restrições que deveriam ter sido explicitadas?
• Conformidade operacional: o sistema preserva propriedades de segurança, integridade, disponibilidade, desempenho e rastreabilidade nas condições previstas e em situações adversas?

Uma implementação pode satisfazer o primeiro plano e falhar nos dois seguintes. Essa é uma das razões pelas quais gerar código não equivale a certificar um sistema. A norma ISO/IEC/IEEE 29148:2018 trata a Engenharia de Requisitos como um processo de definição, gestão e estruturação de requisitos ao longo do ciclo de vida — não como simples redação de um pedido [2].

Parte II — O problema semântico: quando a inferência preenche a lacuna errada

A IA generativa consegue preencher lacunas de uma especificação mediante inferências. Essa capacidade pode facilitar protótipos, levantar alternativas e sugerir requisitos ausentes. Entretanto, também pode introduzir decisões que o operador não autorizou nem reconhece.

Considere um sistema de catálogo comercial. A instrução “permita que cada produtor altere seus próprios produtos” parece suficiente para gerar uma interface funcional. Mas quais condições definem a titularidade do catálogo? Uma associação pode administrar produtos de vários produtores? Um funcionário pode editar os dados do estabelecimento? Como o sistema deve tratar a sessão autenticada, alterações simultâneas e registros de auditoria? A interface pode funcionar corretamente no fluxo principal e, ainda assim, permitir que um usuário altere registros de terceiros.

Nesse exemplo, o programa pode não conter qualquer erro sintático. A falha está na tradução incompleta da intenção para requisitos verificáveis e, possivelmente, na ausência de controles de autorização. Para aceitar a implementação, não basta clicar no botão “Salvar”: é necessário testar também que o produtor A não consegue modificar o catálogo do produtor B. O requisito negativo é tão importante quanto o positivo.

O preenchimento inferencial não é, por definição, inadequado. Torna-se arriscado quando hipóteses geradas pelo modelo passam a operar como decisões aprovadas. Por isso, inferências relevantes devem ser identificadas, registradas e submetidas a validação antes da implantação.

Parte III — Quem possui capacidade para checar?

O ponto crítico não está apenas na competência necessária para solicitar uma solução, mas na competência para avaliar o que foi construído. Quem desconhece PHP, Java ou Rust pode verificar se uma tela apresenta um resultado esperado; em regra, não conseguirá, sem apoio especializado, avaliar controles de autorização, tratamento de exceções, concorrência, integridade transacional, dependências e superfícies de ataque.

É indispensável diferenciar papéis. O usuário final não precisa compreender internamente toda aplicação que utiliza. O responsável pelo produto precisa conhecer o domínio do problema, definir critérios de aceitação e assegurar que exista um processo de validação adequado. A equipe técnica de verificação, que pode ser interna ou contratada, precisa dominar os métodos necessários para avaliar requisitos, implementação e riscos. Em sistemas críticos, a suficiência dessa equipe deve ser demonstrável.

Portanto, a qualificação crescente do operador não significa que todo usuário de um portal deva tornar-se programador. Significa que a responsabilidade pela aceitação de um sistema não pode fundamentar-se exclusivamente na confiança em uma saída que ninguém sabe examinar. A capacidade de checagem pode estar distribuída entre profissionais, ferramentas e processos; não pode estar ausente.

O NIST, por meio do Secure Software Development Framework (SSDF), recomenda práticas de desenvolvimento seguro, incluindo requisitos de segurança, rastreamento de decisões e atividades de identificação e tratamento de vulnerabilidades [3]. A OWASP, em seu Application Security Verification Standard (ASVS), oferece requisitos verificáveis para aplicações web [4]. São referenciais técnicos, não substitutos para a avaliação contextual do sistema.

Parte IV — Produzir em segundos, verificar em horas: a assimetria de capacidade

A velocidade da geração automatizada pode superar amplamente a capacidade humana de examinar os resultados. Um modelo produz dezenas de arquivos e milhares de linhas de código em um intervalo no qual um profissional ainda está identificando dependências e fluxos de dados. Há, assim, uma assimetria entre capacidade de produção e capacidade de supervisão.

Solicitar à própria IA que confira integralmente sua produção pode ajudar, mas não constitui validação independente. O modelo pode repetir a interpretação equivocada do pedido original. Mesmo uma segunda IA, utilizada como revisora, pode reproduzir pressupostos semelhantes. A independência relevante está sobretudo nos critérios de aceitação, nos casos de teste, nas restrições e nos mecanismos de verificação que não dependem de o gerador declarar que acertou.

A verificação deve combinar, proporcionalmente ao risco, revisão técnica, testes positivos e negativos, análise estática, análise de dependências, testes de segurança, observabilidade, segregação de ambientes e possibilidade de reversão. Nenhum conjunto finito de testes oferece garantia absoluta de ausência de falhas; sua função é construir evidências proporcionais ao uso pretendido e revelar defeitos antes que atinjam operações reais.

Na estrutura do NIST AI RMF, os processos de governar, mapear, medir e gerenciar riscos são contínuos ao longo do ciclo de vida [5]. O perfil dedicado à IA generativa reforça a necessidade de tratar riscos específicos dessa tecnologia [6]. Os documentos são orientações voluntárias; não constituem certificação automática de conformidade.

Parte V — A lição aplicada aos agentes: propor não é autorizar

Em ecossistemas inteligentes, a checagem não deve ocorrer apenas após o resultado. É possível incorporar controles antes, durante e depois da execução. Um arranjo arquitetural prudente estabelece a seguinte separação de responsabilidades:

Intenção do usuário → Proposta estruturada da LLM → Validação independente de contexto, autorização e parâmetros → Execução por rotina com privilégios mínimos → Registro dos efeitos → Verificação do resultado.

A LLM atua como componente de interpretação e proposta. O mecanismo executor somente realiza operações previstas, dentro de limites técnicos explicitamente programados. A autenticação, a autorização e as políticas de acesso devem ser aplicadas no sistema responsável pela operação, não inferidas livremente a cada resposta do modelo.

Essa separação corresponde a preocupações registradas pela OWASP na categoria LLM06:2025 — Excessive Agency, que descreve riscos decorrentes de funções, permissões ou autonomia excessivas atribuídas a modelos e agentes [7]. Também se relaciona às recomendações do SSDF sobre desenvolvimento seguro [3].

Esse desenho não torna o sistema infalível: o validador, os scripts e as políticas também precisam ser especificados, testados e monitorados. Contudo, reduz a superfície de consequências de uma resposta inadequada. A IA pode sugerir a ação; a autorização deve pertencer a um mecanismo de controle confiável e verificável.

Parte VI — Alfabetização tecnológica e absorção social

A dificuldade de checagem encontra um obstáculo anterior: a dificuldade de interação com sistemas digitais. Na operação de portais regionais voltados ao setor agropecuário e ao turismo, observam-se dúvidas já no preenchimento de cadastros, na identificação de elementos interativos e na interpretação de serviços de inteligência de mercado. Essas observações são relatos operacionais, não resultados de amostra estatística representativa; além da familiaridade dos usuários, a própria usabilidade da interface precisa ser examinada.

A pesquisa TIC Domicílios 2025, do Cetic.br, investiga competências digitais da população brasileira e oferece uma base empírica para estudar desigualdades de uso e de habilidades [8]. É imprudente presumir que a simples disponibilização de ferramentas inteligentes produzirá capacidade equivalente de utilizá-las criticamente.

Há uma distinção econômica decisiva: empresas tecnicamente capacitadas podem automatizar atividades mesmo quando a maior parte da população não conhece a tecnologia. Portanto, baixa alfabetização digital não impede deslocamentos ocupacionais, mas condiciona a velocidade, a distribuição dos ganhos e as oportunidades de adaptação. As sucessivas mecanizações — do tear industrial aos sistemas de transporte — mostram que inovação tecnológica altera a organização do trabalho e amplia a capacidade produtiva sem preservar necessariamente as ocupações anteriores. A evidência contemporânea, contudo, exige prudência ao extrapolar efeitos: uma revisão da OIT de junho de 2026 identifica ganhos de produtividade heterogêneos e deslocamento ocupacional generalizado ainda limitado nas evidências examinadas [9].

O desafio social não é interromper a inovação, mas reduzir a distância entre a capacidade tecnológica disponível e a capacidade de absorvê-la, empregá-la e supervisioná-la. Essa formação não se obtém instantaneamente; requer educação, adaptação organizacional e experiência prática.

Parte VII — Liberdade de uso, risco e conformidade

Não exigir autorização individual do governo para toda aplicação de IA não significa ausência de limites. A liberdade de uso é relativa à finalidade, ao risco e às leis aplicáveis. Na União Europeia, o Regulamento (UE) 2024/1689 adota uma estrutura de obrigações proporcionais às categorias de uso, com requisitos de gestão de riscos, documentação e supervisão para sistemas de alto risco, observadas as regras e datas específicas de aplicação [10].

No Brasil, a RDC Anvisa nº 657/2022 estabelece requisitos de regularização para softwares enquadrados como dispositivos médicos — não para todo software empregado em instituições de saúde [11]. A LGPD, por sua vez, alcança operações de tratamento de dados pessoais independentemente de terem sido implementadas por humanos ou com auxílio de IA [12].

O ponto técnico é que uma implementação funcional não constitui, por esse fato isolado, uma implementação autorizada ou conforme. Não se deve, entretanto, afirmar que toda inferência será proibida por legislação futura. O que normas e autoridades podem exigir é demonstração proporcional de qualidade, segurança, rastreabilidade, validação e responsabilidade. A ISO/IEC 42001:2023 oferece um referencial para sistemas de gestão de IA nas organizações [13].

3. Considerações técnicas: transformar “marca checar” em procedimento

A expressão de comando precisa converter-se em método. Para cada alteração gerada por IA destinada a um ambiente operacional, recomenda-se produzir ao menos uma cadeia de evidências suficiente para o risco envolvido:

A matriz é uma proposta operacional de síntese, não um checklist oficial do NIST, da ISO ou da OWASP. Sua execução deve ser proporcional à criticidade do sistema. Em um protótipo isolado, os controles podem ser simples. Em uma operação que modifique dados de terceiros, envolva pagamentos ou produza consequências relevantes para pessoas, a comprovação precisa ser mais rigorosa.

A supervisão humana também não deve ser um gesto simbólico: aprovar automaticamente uma saída incompreendida não produz controle efetivo. A expressão human-in-the-loop só possui significado técnico quando o interveniente — pessoa ou equipe — dispõe de informações, competência, autoridade e tempo para detectar desvios e interromper ações inadequadas.

4. Conclusão

A inteligência artificial modificou profundamente a relação entre intenção humana e implementação computacional. Hoje, escrever código pode ser a parte menos difícil de uma tarefa. Formular requisitos suficientes, antecipar riscos, determinar critérios de aceite e conferir o comportamento produzido continuam sendo problemas de Engenharia.

A experiência sintetizada na expressão “marca checar” oferece uma regra simples, mas exigente: a execução declarada não substitui a verificação do resultado. A advertência “a IA pode cometer erros” deve ser interpretada como instrução operacional para criar mecanismos de controle, não apenas como ressalva genérica de responsabilidade.

Não se exige que cada usuário final domine PHP, Java, Rust ou segurança cibernética. Exige-se que, quando um produto for aceito e colocado em operação, haja competência técnica e evidências proporcionais para sustentar essa decisão. A democratização da geração de software não equivale à democratização instantânea de sua validação.

Quanto mais sistemas uma IA consegue produzir, mais relevante se torna identificar quem especificou, quem autorizou, quem verificou e quem responde pelo resultado. Essa é a passagem da confiança na aparência para a Engenharia apoiada em evidências.

“A IA pode entregar o código e declarar ‘pronto’. A responsabilidade técnica começa quando alguém pergunta: ‘foi verificado?’”

— Cleomar Marques, Ph.D.

Referências

1. MARQUES, Cleomar. Quanto Mais Poderosa a IA, Menos Bastará Saber Pedir — Será Preciso Saber Especificar. CM²O, 2026. https://www.cm2o.com.br/pp/artigos/evolucao_ias_cm2o.html.
2. ISO; IEC; IEEE. ISO/IEC/IEEE 29148:2018 — Systems and software engineering — Life cycle processes — Requirements engineering. https://committee.iso.org/standard/72089.html.
3. NIST. SP 800-218 — Secure Software Development Framework (SSDF), Version 1.1. 2022. https://csrc.nist.gov/pubs/sp/800/218/final.
4. OWASP. Application Security Verification Standard (ASVS), 5.0.0. 2025. https://asvs.owasp.org/.
5. NIST. Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1. 2023. https://doi.org/10.6028/NIST.AI.100-1.
6. NIST. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1. 2024. https://doi.org/10.6028/NIST.AI.600-1.
7. OWASP. LLM06:2025 — Excessive Agency. Página oficial de referência do projeto.
8. CETIC.BR / NIC.BR. Pesquisa TIC Domicílios 2025. https://cetic.br/pt/arquivos/domicilios/2025/individuos/.
9. MEROLA, Rossana et al. The impact of GenAI on jobs, productivity and work organization: a review of the empirical evidence. Organização Internacional do Trabalho, 2026. https://doi.org/10.54394/00034628.
10. UNIÃO EUROPEIA. Regulamento (UE) 2024/1689 — Artificial Intelligence Act. https://eur-lex.europa.eu/eli/reg/2024/1689.
11. BRASIL. ANVISA. RDC nº 657, de 24 de março de 2022 — Regularização de software como dispositivo médico. Texto oficial.
12. BRASIL. Lei nº 13.709/2018 — Lei Geral de Proteção de Dados Pessoais (LGPD). https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709compilado.htm.
13. ISO; IEC. ISO/IEC 42001:2023 — Artificial intelligence — Management system. https://www.iso.org/standard/81230.html.

Cleomar Marques, Ph.D.
CM²O — IA, RPA & Inteligência de Dados

Declaração de uso de Inteligência Artificial — O presente texto foi elaborado com assistência do ChatGPT (OpenAI, GPT-6) em etapas de debate crítico, contraposição de argumentos, estruturação, redação e identificação de referências. A ferramenta não é apresentada como autora nem como fonte científica. A tese e as experiências relatadas são atribuídas ao autor indicado, a quem cabem a revisão final, a confirmação das referências e a responsabilidade pelo texto eventualmente publicado.