As obrigações da fase de desenvolvimento previstas no AI Act da UE transformam-se em trabalho de engenharia muito antes de qualquer pessoa redigir um parecer jurídico. O curso concentra-se nas obrigações do fornecedor — isto é, os deveres atribuídos à equipe que disponibiliza um sistema de IA —, uma vez que engenheiros e cientistas de dados geram a maior parte das evidências das quais esses deveres dependem. As equipes frequentemente não percebem isso, pois o trabalho parece consistir apenas na criação de funcionalidades, enquanto a aprovação ou reprovação posterior depende do que foi registrado, testado e mantido consistente entre as versões. A falha comum não decorre de má intenção, mas sim de uma lacuna entre o que o sistema faz e o que a equipe consegue comprovar que ele faz.
Um fornecedor só consegue justificar um lançamento quando o desenvolvimento possui uma estrutura clara desde o início. Essa estrutura começa pela definição do sistema que está sendo criado, sua finalidade e o que ele pode ou não fazer no ambiente real de operação. Inclui também os dados de entrada utilizados, os controles implementados, os registros (logs) existentes e as ações que um humano pode realizar quando o resultado parecer incorreto. É importante visualizar esses aspectos em conjunto, pois a ausência de algum elemento geralmente só é descoberta depois que a equipe já realizou o treinamento, a integração e a implementação. O mapa abaixo apresenta o panorama completo antes de se abordar cada parte individualmente.
Neste curso, um sistema de IA não é apenas um arquivo de modelo ou um prompt engenhoso. Trata-se de toda a estrutura que recebe entradas de um processo de trabalho, gera saídas nas quais as pessoas confiam e se comporta de maneiras moldadas pelo código, pelos dados, pela configuração e pela interface que o cerca. É por isso que uma pequena alteração em um pipeline pode mudar o efeito do sistema no mundo real, mesmo que os pesos do modelo permaneçam inalterados. [fontes][/fontes]
Uma equipe pode pensar que está “apenas integrando um modelo”, mas o objeto regulamentado é o sistema montado assim que ele passa a incorporar decisões, recomendações ou conteúdo gerado a um fluxo de trabalho. O processo de treinamento, o repositório de features (feature store), o índice de recuperação, as salvaguardas (guardrails), as regras de monitoramento e os textos da interface (UI copy) determinam, em conjunto, o que o usuário vê e o que ele tem permissão para fazer em seguida. Se esses componentes não estiverem vinculados a uma versão e a um propósito específicos, os testes e a documentação posteriores não corresponderão ao que foi efetivamente entregue. [fontes][/fontes]
Engenheiros e cientistas de dados geralmente são os responsáveis pelas escolhas que definem o propósito, as entradas e os limites do sistema, pois essas decisões ocorrem em tickets, conjuntos de dados, planos de avaliação e revisões de código. As equipes jurídicas e de compliance podem interpretar a legislação, mas não conseguem reconstruir o que o modelo processou durante o treinamento ou o que a interface permitiu no momento da decisão. A equipe de produto pode definir objetivos, mas não consegue substituir registros (logs) ausentes nem reexecutar um experimento que não foi rastreado. [fontes][/fontes]
A transição para as equipes de implementação (deployers) também começa na fase de construção. Essas equipes precisam de instruções claras, transparência utilizável na interface e mecanismos de supervisão que funcionem sob pressão, pois um PDF com políticas não compensa um sistema que oculta sua própria incerteza ou impede intervenções. Quando os desenvolvedores tratam esses aspectos como “burocracia para depois”, geralmente acabam tendo que fazer ajustes improvisados na interface e reescrever a documentação para que correspondam à realidade — um processo mais lento do que projetar tudo corretamente desde o início. [fontes][/fontes]
Antes de prosseguir, é útil identificar quais modos de falha já são familiares. [fontes][/fontes]