O padrão ETSI EN 304 223 estabelece requisitos básicos de segurança para IA que empresas devem integrar em seus frameworks de governança.
À medida que organizações incorporam aprendizado de máquina em suas operações centrais, essa Norma Europeia (EN) fixa disposições concretas para proteger modelos e sistemas de IA. Trata‑se do primeiro padrão europeu de cibersegurança para IA aplicável globalmente, tendo recebido aprovação formal de Organismos Nacionais de Normalização, o que reforça sua autoridade em mercados internacionais.
O documento atua como um referencial necessário, complementando o AI Act da UE. Reconhece que sistemas de IA apresentam riscos específicos — como suscetibilidade a data poisoning, ofuscação de modelos (model obfuscation) e injeção indireta de prompts — que muitas vezes escapam às medidas tradicionais de segurança de software. O escopo abrange desde redes neurais profundas e IA generativa até sistemas preditivos básicos, excluindo explicitamente apenas usos estritamente acadêmicos.
Clarificação da cadeia de responsabilidade
Um obstáculo persistente na adoção empresarial de IA é identificar quem responde pelo risco. O padrão ETSI resolve isso definindo três papéis técnicos principais: Developers (Desenvolvedores), System Operators (Operadores de Sistema) e Data Custodians (Custódios de Dados).
Na prática, esses papéis frequentemente se confundem. Por exemplo, uma instituição financeira que afina um modelo open source para detecção de fraudes atua simultaneamente como Desenvolvedor e Operador de Sistema. Essa dupla condição acarreta obrigações rigorosas: a organização deve proteger a infraestrutura de implantação e, ao mesmo tempo, documentar a proveniência dos dados de treino e auditar o desenho do modelo.
A inclusão dos Custódios de Dados como grupo distinto impacta diretamente cargos como Chief Data and Analytics Officers (CDAOs). Esses responsáveis controlam permissões e integridade dos dados e passam a ter responsabilidades de segurança explícitas: verificar se o uso previsto do sistema está alinhado à sensibilidade dos dados de treinamento, funcionando como um mecanismo de bloqueio de segurança no fluxo de gestão de dados.
Segurança incorporada desde o desenho
O padrão deixa claro que a segurança não pode ser um apêndice na fase de implantação. Na etapa de desenho, as organizações devem conduzir modelagem de ameaças que contemple ataques nativos de IA, como membership inference (inferência de membros) e model obfuscation (ofuscação de modelos).
Uma exigência prevê que desenvolvedores limitem funcionalidades para reduzir a superfície de ataque. Por exemplo, se um sistema usa um modelo multimodal, mas só necessita de processamento de texto, as modalidades não utilizadas (como imagem ou áudio) representam um risco que precisa ser mitigado. Isso força líderes técnicos a reavaliarem práticas correntes, como a implantação de grandes foundation models genéricos quando um modelo menor e mais especializado seria suficiente.
Gestão de ativos, recuperação e cadeias de suprimentos
O padrão também impõe gestão rigorosa de ativos. Desenvolvedores e Operadores de Sistema devem manter inventários detalhados de ativos, incluindo interdependências e conectividade — o que facilita a descoberta de shadow AI; gestores de TI não conseguem proteger modelos que desconhecem. Além disso, exige planos de recuperação de desastres específicos para ataques a IA, garantindo que um “estado conhecido bom” possa ser restaurado caso um modelo seja comprometido.
A segurança da cadeia de suprimentos é um ponto de atrito para empresas que dependem de fornecedores terceirizados ou repositórios open source. O ETSI determina que, se um Operador de Sistema optar por usar modelos ou componentes pouco documentados, deve justificar a escolha e documentar os riscos de segurança associados. Na prática, equipes de compras não podem mais aceitar soluções “caixa‑preta” sem questionamentos: desenvolvedores precisam fornecer hashes criptográficos dos componentes do modelo para verificar autenticidade. Quando dados de treinamento são obtidos publicamente — prática comum em LLMs — os desenvolvedores devem registrar a URL de origem e o carimbo de data/hora da aquisição. Esse rastro de auditoria é essencial em investigações pós‑incidente, sobretudo ao tentar identificar se um modelo sofreu data poisoning durante seu treino.
Controles de API, ciclo de vida e monitoramento contínuo
Empresas que oferecem APIs para clientes externos devem aplicar controles para mitigar ataques focados em IA, como limitação de taxa (rate limiting) para evitar que adversários reconstituam o modelo ou contornem defesas para injetar dados envenenados.
A abordagem por ciclo de vida estende‑se à manutenção: atualizações relevantes — por exemplo, retrainings com novos dados — são tratadas como implantação de uma nova versão, o que exige novos testes e avaliações de segurança conforme o padrão. O monitoramento contínuo também é formalizado: Operadores de Sistema devem analisar logs não apenas para disponibilidade, mas para detectar “data drift” ou mudanças graduais no comportamento que possam indicar uma violação. Isso transforma o monitoramento de IA de métrica de desempenho em disciplina de segurança.
Fim de vida e governança executiva
Na fase de End of Life, quando um modelo é descomissionado ou transferido, os Custódios de Dados devem ser envolvidos para assegurar a eliminação segura de dados e detalhes de configuração, prevenindo o vazamento de propriedade intelectual sensível ou dados de treinamento por meio de hardware descartado ou instâncias em nuvem esquecidas.
A conformidade com o ETSI EN 304 223 também exige revisão dos programas de treinamento em segurança cibernética. O padrão determina que os treinamentos sejam adaptados a funções específicas: desenvolvedores precisam compreender práticas seguras de codificação para IA, enquanto demais colaboradores devem ser conscientizados sobre ameaças, como engenharia social via saídas de IA.
Comentário institucional
Scott Cadzow, presidente do Comitê Técnico da ETSI para Segurança em Inteligência Artificial, comentou: “O ETSI EN 304 223 representa um passo importante para estabelecer uma base comum e rigorosa na proteção de sistemas de IA. Num momento em que a IA é cada vez mais integrada a serviços e infraestruturas críticas, a disponibilidade de orientações claras e práticas, que reflitam tanto a complexidade dessas tecnologias quanto as realidades da implantação, não pode ser subestimada. O trabalho que resultou neste framework é fruto de ampla colaboração e permite que organizações tenham confiança em sistemas de IA resilientes, confiáveis e seguros por design.”
Implementar as linhas‑base previstas pelo padrão — com trilhas de auditoria documentadas, definições de papéis claras e transparência na cadeia de suprimentos — oferece uma estrutura para inovação mais segura, ajudando empresas a mitigar riscos associados à adoção de IA e a consolidar posição defensável em auditorias regulatórias futuras.
A ETSI prepara um relatório técnico complementar (ETSI TR 104 159) que aplicará esses princípios especificamente à IA generativa, com foco em problemas como deepfakes e desinformação.
