Este curso aborda as decisões de construção de IA responsável voltadas para engenheiros que lançam sistemas de IA, fundamentando-se no AI Act da UE (Regulamento (UE) 2024/1689). O foco está no trabalho do fornecedor — ou seja, nas escolhas que transformam um modelo ou pipeline em um produto que pode ser devidamente justificado. Neste curso, IA responsável significa projetar, documentar, governar e lançar sistemas de modo que seus limites sejam claros e seu comportamento seja controlável. O erro comum das equipes é tratar as obrigações do fornecedor apenas como burocracia a ser cumprida no momento do lançamento. Embora pareça tratar-se apenas de redigir documentos tardiamente, o trabalho é definido muito antes, por meio de escolhas de design e de dados. É por isso que o curso retorna constantemente a artefatos que podem ser nomeados e versionados. Construímos o mapa antes de detalhar os pontos específicos, permitindo que você aloque cada dever em seu devido lugar.
Uma equipe fornecedora já realiza grande parte desse trabalho de forma dispersa: documento de arquitetura, model card (ficha do modelo), notebook de avaliação, checklist de lançamento e painel de monitoramento. O problema é que esses artefatos nem sempre estão alinhados a um propósito único pretendido, criando lacunas entre as equipes. Quando essas lacunas existem, os responsáveis pela implementação subsequente não conseguem operar o sistema com segurança, pois não sabem para que ele foi construído ou como se comporta sob estresse. O curso aborda as obrigações do fornecedor estruturando o processo de construção e lançamento em três fases: design e dados; marcos de lançamento e evidências; e monitoramento pós-mercado e gestão de incidentes. Essa estrutura é o que torna as lições subsequentes práticas e aplicáveis. Veja abaixo uma visão geral dessa estrutura:
Neste curso, um sistema de IA é um sistema baseado em máquina, projetado para operar com níveis variados de autonomia, que infere como gerar saídas — como previsões, conteúdo, recomendações ou decisões — a partir das entradas que recebe. Um provedor é a pessoa ou organização que desenvolve um sistema de IA (ou manda desenvolvê-lo) e o coloca no mercado ou em operação sob seu próprio nome ou marca, seja de forma paga ou gratuita. Essa definição é importante para engenheiros porque é possível tornar-se o provedor sem treinar os pesos base, simplesmente por ser o responsável pelo sistema entregue e por sua finalidade pretendida. Você cruza essa linha quando os usuários vivenciam seu sistema como o produto final e sua equipe controla o que ele faz.
Usar um modelo de terceiros não torna automaticamente esse terceiro o provedor de tudo o que você entrega. Sua equipe ainda decide quais dados entram, o que as saídas significam e quais mecanismos de proteção (guardrails) existem na interface. Essas escolhas definem a finalidade pretendida na prática, mesmo que o marketing nunca utilize essa expressão. Quando um parceiro pergunta “Quem é o provedor aqui?”, ele está perguntando quem pode produzir o rastro de evidências, e não quem escreveu a primeira linha de código do modelo.
Os engenheiros são responsáveis pelas partes do trabalho do provedor que só a implementação técnica pode concretizar. As equipes de conformidade e jurídica podem ajudar a interpretar o AI Act (Lei de IA da UE), mas não conseguem implementar retroativamente sistemas de registro (logging), pontos de monitoramento ou cobertura de avaliação após o lançamento. A dificuldade recorrente reside em traduzir uma obrigação legal em algo concreto que possa ser apontado em um repositório, em uma execução de testes ou em um critério de liberação (release gate). É nessa tradução que os projetos geralmente perdem o rumo, pois ela envolve múltiplas equipes e cronogramas. Quando o processo funciona bem, o resultado da engenharia é algo previsível e passível de verificação.
Uma equipe que executa isso bem repete sempre a mesma estratégia: define a finalidade pretendida logo no início e, em seguida, vincula a ela as escolhas de design e a documentação. Elas tratam a documentação como um espelho da implementação, e não como uma narrativa escrita posteriormente; assim, ela permanece versionada juntamente com o sistema. Também separam o que deve ser verdadeiro antes da colocação no mercado daquilo que deve continuar funcionando após o lançamento, pois a entrega do produto altera o que ainda pode ser corrigido a baixo custo. Se você consegue nomear o artefato correspondente a uma obrigação, consegue também definir um responsável e uma data para ele.
[fontes][/fontes]