Governança de IA na Engenharia: O Que um Arquiteto Deve Saber
Este artigo explora a governança de IA sob a ótica de um arquiteto de sistemas, destacando a importância de integrar a segurança e o controle de riscos desde o início do projeto. Discute-se como a falta de governança pode levar a problemas legais e financeiros, exemplificado pelo caso da Air Canada, e apresenta as tendências atuais e melhores práticas para uma governança de IA eficaz.
MundiX News·15 de maio de 2026·15 min de leitura·👁 10 views
Governança de IA na Engenharia: O Que um Arquiteto Deve Saber
Olá a todos, meu nome é Sergey Proshchaev. Sou Tech Lead e chefe da área de desenvolvimento Java / Kotlin na FinTech, e também leciono em cursos de desenvolvimento e arquitetura na OTUS. Neste artigo, quero discutir a Governança de IA — um tema que, há alguns anos, parecia ser o domínio de gerentes de conformidade entediantes, mas hoje determina se seu produto de IA sobreviverá ou arrastará a empresa para perdas de centenas de milhões.
Eu vejo a Governança de IA não como um advogado e nem como um gerente de produto. Eu vejo como um arquiteto. Uma pessoa que precisa ver todo o sistema como um todo, prever gargalos e projetar para que nada desmorone nem na produção, nem no tribunal. E vou ser honesto: depois de algumas disputas de trabalho com a realidade, parei de tratar esse tópico como um fardo burocrático. E é por isso.
O momento em que a Governança deixa de ser uma abstração
Quando um arquiteto ouve a frase “Governança de IA”, imagens de tabelas, regulamentos e políticas intermináveis, que são escritas por uma questão de formalidade, muitas vezes surgem em sua cabeça. Essa é uma reação de defesa normal. Eu mesmo pensava assim, até que um dia me deparei com uma pergunta simples do serviço de segurança da informação: “Seu novo recurso generativo, que escreve respostas em nome de um funcionário — entendemos em que condições ele pode dizer o que não pode ser dito? E quem será responsável por isso?”
Era FinTech. Há muito dinheiro em jogo, a reputação é ainda mais valiosa. Eu me peguei pensando que não apenas não sabíamos a resposta — nem sequer formulamos os critérios para “comportamento inaceitável” do modelo. Testamos a precisão das respostas, atrasos e até mesmo a tonalidade. Mas nenhum dos engenheiros fez a pergunta: “E se o modelo começar a dar recomendações financeiras, fingindo ser uma pessoa?” E aqui eu vi um problema profundo: o desenvolvimento estava correndo para frente, e não havia controle arquitetônico sobre o comportamento não determinístico.
A partir desse momento, percebi: Governança de IA não é sobre papelada. É sobre uma visão sistêmica dos riscos, que deve ser embutida na arquitetura desde o início. E se você não fizer isso, o tribunal o fará por você.
O que o chatbot canadense nos ensinou: o caso da Air Canada
Para não ser infundado, vamos relembrar uma história real que explodiu em 2023–2024 e se tornou um clássico de “como não fazer”. A companhia aérea canadense Air Canada introduziu um chatbot em seu site para suporte ao cliente. IA generativa comum, treinada em uma base de conhecimento da empresa. Tudo correu bem até que um passageiro perguntou ao bot se era possível obter um desconto no bilhete sob uma tarifa especial para parentes enlutados (tarifa de luto).
O chatbot respondeu com confiança: sim, você pode comprar um bilhete pelo preço total agora e, em seguida, solicitar um reembolso da diferença de acordo com a política da empresa. O problema era que a Air Canada não tinha essa política. O modelo simplesmente inventou — alucinações funcionaram, uma coisa típica para LLM.
O passageiro, como você entende, fez exatamente o que o bot aconselhou e, em seguida, solicitou uma indenização. A empresa se recusou, dizendo: “o bot é uma entidade separada, você deveria ter lido as regras oficiais no site”. O caso foi parar no tribunal. E o tribunal ficou do lado do passageiro, obrigando a Air Canada a pagar uma indenização e, na verdade, reconhecendo que a empresa é totalmente responsável por tudo o que seu instrumento de IA gera.
Para mim, como arquiteto, foi um tapa na cara. A empresa economizou na camada de gerenciamento: não havia um contrato claro entre o modelo e as regras de negócios, não havia validação das respostas para conformidade com as políticas reais, não havia monitoramento de alucinações. Isso não é um bug de código — é uma falha na governança arquitetônica. E o preço da questão não é apenas dinheiro, mas também um precedente que agora aparecerá em todos os riscos de IA.
Três principais tendências de Governança de IA em 2026
Agora, vamos analisar o que mudou e no que as equipes fortes estão focando. Eu deliberadamente não vou jogar abreviações de relatórios da Gartner, mas vou dizer o que realmente está acontecendo no terreno.
Tendência 1: Dos princípios voluntários ao controle automático
Por muito tempo, a principal ferramenta foram os princípios éticos. As empresas publicaram belos documentos “Nossos princípios de IA responsável” — e foi aí que tudo acabou. Em 2026, nenhum cliente ou regulador sério (não importa em que país) aceitará mais palavras pela fé. Todos querem ver evidências.
Como isso se parece na prática: ferramentas de verificação automatizada de modelos para conformidade com as políticas estão aparecendo. Por exemplo, guardrails (limitadores) em torno de LLMs, que filtram temas proibidos em tempo real, bloqueiam o vazamento de PII ou impedem a geração de obrigações em nome da empresa. Em grandes projetos empresariais, camadas de proxy especiais são introduzidas, que validam cada solicitação e resposta do modelo mesmo antes de chegar ao usuário.
Eu mesmo vejo como as equipes, que antes gastavam semanas em testes de penetração, agora colocam políticas automáticas no nível do gateway de API. Este é um padrão arquitetônico que pode e deve ser projetado com antecedência.
Tendência 2: Gerenciamento completo do ciclo de vida dos riscos do modelo
Lembra da tarefa de teste para um analista de sistema, onde eles perguntam sobre “verificação do usuário”? Aproximadamente a mesma armadilha espera por você aqui. Muitos pensam: “Treinamos o modelo, testamos, executamos a verificação — tudo”. E eles esquecem que o modelo se degrada. Os dados derivam. Novas ataques aparecem. O que funcionou ontem pode se comportar de forma imprevisível hoje.
Portanto, uma das principais tendências é o gerenciamento completo do ciclo de vida. Começa não no momento do treinamento, mas já na fase de definição da tarefa: podemos medir a justiça? Podemos detectar a deriva? Os valores limite para o rollback automático são definidos?
Equipes fortes estão implementando Model Risk Management (MRM), semelhante em espírito ao gerenciamento de risco operacional em finanças. Eu vi como, em um banco, um “passaporte de risco” foi iniciado para cada modelo de ML, que descreve os limites de aplicabilidade, gatilhos de retreinamento e métricas precisas pelas quais o modelo é desligado sem a participação humana. Esta é uma abordagem arquitetônica.
Tendência 3: Transparência e explicabilidade deixam de ser uma formalidade
A explicabilidade tem sido apresentada por muito tempo como um recurso acadêmico. Mas, no mundo real, as empresas não se importam com a forma como as camadas da rede neural são organizadas. Enquanto ela comete erros em uma fração de porcentagem e não viola a lei — tudo bem para todos. No entanto, em domínios sensíveis (pontuação de crédito, medicina, RH), um modelo não transparente se tornou um risco direto para os negócios.
Eu observo como, em contratos B2B, o item “direito à explicação da decisão” está aparecendo cada vez mais. O cliente não quer apenas uma API com a resposta “recusado”, mas o motivo, formulado em linguagem humana. Isso força a revisão da arquitetura: usar conjuntos com modelos interpretáveis no topo de “caixas pretas”, introduzir camadas de explicações post-hoc (SHAP, LIME) diretamente nos pipelines.
Como arquiteto, vejo isso da seguinte forma: se não conseguimos explicar a decisão do sistema, não controlamos seu comportamento. E, portanto, não controlamos o processo de negócios. Isso é insuportável para qualquer empresa séria.
Figura 2 — Mapa dos principais riscos do projeto de IA que a governança cobre
Com base neste diagrama (Figura 2), os riscos em projetos de IA não são jogados em um monte, mas se espalham por quatro áreas principais — Dados, Modelo, Segurança e Conformidade / Negócios.
Cada ramificação mostra pontos problemáticos específicos: da qualidade dos dados e da deriva do modelo a vazamentos, injeções e responsabilidade legal. E a ideia principal é que a Governança de IA não é uma “preocupação com a segurança” abstrata, mas exatamente sobre como trabalhar sistematicamente com cada uma dessas ramificações, e não apenas derramar problemas no nível do código.
Tendência 4: Governança como código — quando as políticas vivem em CI/CD
Antes, a verificação de conformidade era manual: antes do lançamento, a equipe coletava artefatos e os mostrava ao departamento de segurança. Isso atrasou tudo. Agora, as melhores práticas estão indo para o fato de que as políticas de controle são versionadas e executadas automaticamente diretamente no pipeline.
Eu vi como os caras de uma startup de IA implementaram verificações no GitHub Actions: se o modelo na solicitação de pull mostrar uma métrica de justiça abaixo do limite — a compilação falha. Tudo. Sem persuasão. Esta é a governança como código. E não é sobre burocracia — é sobre cultura de engenharia, onde a responsabilidade é automatizada.
Figura 3 — Diagrama esquemático: pipeline de Governança de IA nas etapas do ciclo de vida do modelo
A Governança de IA não é uma verificação única antes do lançamento, mas um pipeline contínuo, integrado em todas as etapas da vida do modelo.
Da definição de requisitos (Figura 3), passamos pela validação de dados, treinamento e testes automáticos de justiça / explicabilidade / segurança. A bifurcação principal se torna o portão “Conforme as políticas?”: se não — o lançamento é bloqueado, o modelo vai para a iteração; se sim — é implantado com monitoramento contínuo da deriva e incidentes. E o monitoramento, por sua vez, através do loop de feedback, aciona o retreinamento. A ideia principal é que a governança não seja colada na lateral, mas seja um gateway arquitetônico obrigatório em todo o ciclo de vida.
Melhores práticas e o que eu aprendi com projetos de trabalho
Além das tendências, quero dar algumas práticas específicas que eu mesmo usei ou observei em equipes que realmente trabalham com IA em produção:
“Passaporte do modelo” como um artefato minimamente viável.
Não há necessidade de escrever documentos volumosos. Mas cada modelo de ML significativo deve ter claramente descrito: o objetivo, os limites de aplicabilidade, uma lista de limitações conhecidas, o proprietário e os gatilhos para a retirada de serviço. Isso leva uma página, mas salva de desastres como “ela começou a se comportar de forma estranha, e não sabíamos quem era responsável por ela”.
Divisão de responsabilidade entre as funções.
Na realidade, o serviço de IA não é apenas cientistas de dados. Eu sempre insisto que o arquiteto, o desenvolvedor, o segurança e o proprietário dos requisitos de negócios concordem claramente quem valida os dados, quem assina a precisão, quem é responsável pelo monitoramento de incidentes. Sem isso, a governança se transforma em um jogo de um gol.
Cultura “E se”.
Eu peguei isso da análise de sistemas. Equipes fortes fazem perguntas a si mesmas durante o projeto: “E se nosso modelo começar a gerar conselhos sobre autotratamento? E se for enganado através da injeção de prompt? E se começar a discriminar por gênero?” E não apenas perguntam, mas projetam proteção contra esses cenários. Isso não é paranoia — é higiene arquitetônica.
Transparência para o usuário.
Em produtos B2C, agora considero uma boa forma de rotular honestamente o conteúdo gerado por IA e dar ao usuário a oportunidade de recusar decisões automáticas. Isso reduz os riscos legais e, estranhamente, aumenta a confiança. Testamos: as pessoas são mais leais a um serviço que não tenta fingir ser humano.
Conclusão: o arquiteto é um estrategista, não um supervisor
Quando comecei a entender a Governança de IA, parecia que era um conjunto de restrições que impediam a construção rápida de recursos. Agora, eu o percebo como parte do pensamento arquitetônico. Se seu sistema inclui componentes não determinísticos como LLMs, você simplesmente deve projetar loops de controle. Não é sobre o medo dos reguladores — é sobre responsabilidade profissional.
O caso da Air Canada é uma ilustração perfeita de como a ausência desses loops leva a perdas específicas e precedentes judiciais. Mas eu gosto ainda mais quando a governança bem construída ajuda a equipe a dormir em paz e se concentrar em tarefas de produto, e não em incidentes noturnos.
Se o tema da Governança de IA já deixou de ser abstrato para você e começou a se transformar em uma tarefa de trabalho, você pode continuar a análise na aula aberta da OTUS
“Critérios de qualidade e segurança dos sistemas de IA no produto”
. Será realizado
19 de maio às 20:00
no âmbito do curso
“Estratégia e gerenciamento de IA na empresa”
. Vamos falar sobre como avaliar a qualidade e a segurança dos sistemas de IA, onde colocar os pontos de controle e como construir a governança sem burocracia desnecessária, mas com responsabilidade de engenharia normal.
➡ Inscreva-se na aula aberta
➡ Mais informações sobre o curso
Assine o blog OTUS
— aqui analisamos IA, arquitetura e práticas de engenharia com referência a tarefas reais das equipes.
🛡️⚡
Pare de pesquisar. Comece a hackear.
O MundiX é seu copiloto de pentest com IA: comandos exatos, análise de outputs e próximo passo na kill chain — em segundos.
Sem cartão para começar · Planos a partir de R$49/mês
Governança de IA na Engenharia: O Que um Arquiteto Deve Saber
Olá a todos, meu nome é Sergey Proshchaev. Sou Tech Lead e chefe da área de desenvolvimento Java / Kotlin na FinTech, e também leciono em cursos de desenvolvimento e arquitetura na OTUS. Neste artigo, quero discutir a Governança de IA — um tema que, há alguns anos, parecia ser o domínio de gerentes de conformidade entediantes, mas hoje determina se seu produto de IA sobreviverá ou arrastará a empresa para perdas de centenas de milhões.
Eu vejo a Governança de IA não como um advogado e nem como um gerente de produto. Eu vejo como um arquiteto. Uma pessoa que precisa ver todo o sistema como um todo, prever gargalos e projetar para que nada desmorone nem na produção, nem no tribunal. E vou ser honesto: depois de algumas disputas de trabalho com a realidade, parei de tratar esse tópico como um fardo burocrático. E é por isso.
O momento em que a Governança deixa de ser uma abstração
Quando um arquiteto ouve a frase “Governança de IA”, imagens de tabelas, regulamentos e políticas intermináveis, que são escritas por uma questão de formalidade, muitas vezes surgem em sua cabeça. Essa é uma reação de defesa normal. Eu mesmo pensava assim, até que um dia me deparei com uma pergunta simples do serviço de segurança da informação: “Seu novo recurso generativo, que escreve respostas em nome de um funcionário — entendemos em que condições ele pode dizer o que não pode ser dito? E quem será responsável por isso?”
Era FinTech. Há muito dinheiro em jogo, a reputação é ainda mais valiosa. Eu me peguei pensando que não apenas não sabíamos a resposta — nem sequer formulamos os critérios para “comportamento inaceitável” do modelo. Testamos a precisão das respostas, atrasos e até mesmo a tonalidade. Mas nenhum dos engenheiros fez a pergunta: “E se o modelo começar a dar recomendações financeiras, fingindo ser uma pessoa?” E aqui eu vi um problema profundo: o desenvolvimento estava correndo para frente, e não havia controle arquitetônico sobre o comportamento não determinístico.
A partir desse momento, percebi: Governança de IA não é sobre papelada. É sobre uma visão sistêmica dos riscos, que deve ser embutida na arquitetura desde o início. E se você não fizer isso, o tribunal o fará por você.
O que o chatbot canadense nos ensinou: o caso da Air Canada
Para não ser infundado, vamos relembrar uma história real que explodiu em 2023–2024 e se tornou um clássico de “como não fazer”. A companhia aérea canadense Air Canada introduziu um chatbot em seu site para suporte ao cliente. IA generativa comum, treinada em uma base de conhecimento da empresa. Tudo correu bem até que um passageiro perguntou ao bot se era possível obter um desconto no bilhete sob uma tarifa especial para parentes enlutados (tarifa de luto).
O chatbot respondeu com confiança: sim, você pode comprar um bilhete pelo preço total agora e, em seguida, solicitar um reembolso da diferença de acordo com a política da empresa. O problema era que a Air Canada não tinha essa política. O modelo simplesmente inventou — alucinações funcionaram, uma coisa típica para LLM.
O passageiro, como você entende, fez exatamente o que o bot aconselhou e, em seguida, solicitou uma indenização. A empresa se recusou, dizendo: “o bot é uma entidade separada, você deveria ter lido as regras oficiais no site”. O caso foi parar no tribunal. E o tribunal ficou do lado do passageiro, obrigando a Air Canada a pagar uma indenização e, na verdade, reconhecendo que a empresa é totalmente responsável por tudo o que seu instrumento de IA gera.
Para mim, como arquiteto, foi um tapa na cara. A empresa economizou na camada de gerenciamento: não havia um contrato claro entre o modelo e as regras de negócios, não havia validação das respostas para conformidade com as políticas reais, não havia monitoramento de alucinações. Isso não é um bug de código — é uma falha na governança arquitetônica. E o preço da questão não é apenas dinheiro, mas também um precedente que agora aparecerá em todos os riscos de IA.
Três principais tendências de Governança de IA em 2026
Agora, vamos analisar o que mudou e no que as equipes fortes estão focando. Eu deliberadamente não vou jogar abreviações de relatórios da Gartner, mas vou dizer o que realmente está acontecendo no terreno.
Tendência 1: Dos princípios voluntários ao controle automático
Por muito tempo, a principal ferramenta foram os princípios éticos. As empresas publicaram belos documentos “Nossos princípios de IA responsável” — e foi aí que tudo acabou. Em 2026, nenhum cliente ou regulador sério (não importa em que país) aceitará mais palavras pela fé. Todos querem ver evidências.
Como isso se parece na prática: ferramentas de verificação automatizada de modelos para conformidade com as políticas estão aparecendo. Por exemplo, guardrails (limitadores) em torno de LLMs, que filtram temas proibidos em tempo real, bloqueiam o vazamento de PII ou impedem a geração de obrigações em nome da empresa. Em grandes projetos empresariais, camadas de proxy especiais são introduzidas, que validam cada solicitação e resposta do modelo mesmo antes de chegar ao usuário.
Eu mesmo vejo como as equipes, que antes gastavam semanas em testes de penetração, agora colocam políticas automáticas no nível do gateway de API. Este é um padrão arquitetônico que pode e deve ser projetado com antecedência.
Tendência 2: Gerenciamento completo do ciclo de vida dos riscos do modelo
Lembra da tarefa de teste para um analista de sistema, onde eles perguntam sobre “verificação do usuário”? Aproximadamente a mesma armadilha espera por você aqui. Muitos pensam: “Treinamos o modelo, testamos, executamos a verificação — tudo”. E eles esquecem que o modelo se degrada. Os dados derivam. Novas ataques aparecem. O que funcionou ontem pode se comportar de forma imprevisível hoje.
Portanto, uma das principais tendências é o gerenciamento completo do ciclo de vida. Começa não no momento do treinamento, mas já na fase de definição da tarefa: podemos medir a justiça? Podemos detectar a deriva? Os valores limite para o rollback automático são definidos?
Equipes fortes estão implementando Model Risk Management (MRM), semelhante em espírito ao gerenciamento de risco operacional em finanças. Eu vi como, em um banco, um “passaporte de risco” foi iniciado para cada modelo de ML, que descreve os limites de aplicabilidade, gatilhos de retreinamento e métricas precisas pelas quais o modelo é desligado sem a participação humana. Esta é uma abordagem arquitetônica.
Tendência 3: Transparência e explicabilidade deixam de ser uma formalidade
A explicabilidade tem sido apresentada por muito tempo como um recurso acadêmico. Mas, no mundo real, as empresas não se importam com a forma como as camadas da rede neural são organizadas. Enquanto ela comete erros em uma fração de porcentagem e não viola a lei — tudo bem para todos. No entanto, em domínios sensíveis (pontuação de crédito, medicina, RH), um modelo não transparente se tornou um risco direto para os negócios.
Eu observo como, em contratos B2B, o item “direito à explicação da decisão” está aparecendo cada vez mais. O cliente não quer apenas uma API com a resposta “recusado”, mas o motivo, formulado em linguagem humana. Isso força a revisão da arquitetura: usar conjuntos com modelos interpretáveis no topo de “caixas pretas”, introduzir camadas de explicações post-hoc (SHAP, LIME) diretamente nos pipelines.
Como arquiteto, vejo isso da seguinte forma: se não conseguimos explicar a decisão do sistema, não controlamos seu comportamento. E, portanto, não controlamos o processo de negócios. Isso é insuportável para qualquer empresa séria.
Figura 2 — Mapa dos principais riscos do projeto de IA que a governança cobre
Com base neste diagrama (Figura 2), os riscos em projetos de IA não são jogados em um monte, mas se espalham por quatro áreas principais — Dados, Modelo, Segurança e Conformidade / Negócios.
Cada ramificação mostra pontos problemáticos específicos: da qualidade dos dados e da deriva do modelo a vazamentos, injeções e responsabilidade legal. E a ideia principal é que a Governança de IA não é uma “preocupação com a segurança” abstrata, mas exatamente sobre como trabalhar sistematicamente com cada uma dessas ramificações, e não apenas derramar problemas no nível do código.
Tendência 4: Governança como código — quando as políticas vivem em CI/CD
Antes, a verificação de conformidade era manual: antes do lançamento, a equipe coletava artefatos e os mostrava ao departamento de segurança. Isso atrasou tudo. Agora, as melhores práticas estão indo para o fato de que as políticas de controle são versionadas e executadas automaticamente diretamente no pipeline.
Eu vi como os caras de uma startup de IA implementaram verificações no GitHub Actions: se o modelo na solicitação de pull mostrar uma métrica de justiça abaixo do limite — a compilação falha. Tudo. Sem persuasão. Esta é a governança como código. E não é sobre burocracia — é sobre cultura de engenharia, onde a responsabilidade é automatizada.
Figura 3 — Diagrama esquemático: pipeline de Governança de IA nas etapas do ciclo de vida do modelo
A Governança de IA não é uma verificação única antes do lançamento, mas um pipeline contínuo, integrado em todas as etapas da vida do modelo.
Da definição de requisitos (Figura 3), passamos pela validação de dados, treinamento e testes automáticos de justiça / explicabilidade / segurança. A bifurcação principal se torna o portão “Conforme as políticas?”: se não — o lançamento é bloqueado, o modelo vai para a iteração; se sim — é implantado com monitoramento contínuo da deriva e incidentes. E o monitoramento, por sua vez, através do loop de feedback, aciona o retreinamento. A ideia principal é que a governança não seja colada na lateral, mas seja um gateway arquitetônico obrigatório em todo o ciclo de vida.
Melhores práticas e o que eu aprendi com projetos de trabalho
Além das tendências, quero dar algumas práticas específicas que eu mesmo usei ou observei em equipes que realmente trabalham com IA em produção:
“Passaporte do modelo” como um artefato minimamente viável.
Não há necessidade de escrever documentos volumosos. Mas cada modelo de ML significativo deve ter claramente descrito: o objetivo, os limites de aplicabilidade, uma lista de limitações conhecidas, o proprietário e os gatilhos para a retirada de serviço. Isso leva uma página, mas salva de desastres como “ela começou a se comportar de forma estranha, e não sabíamos quem era responsável por ela”.
Divisão de responsabilidade entre as funções.
Na realidade, o serviço de IA não é apenas cientistas de dados. Eu sempre insisto que o arquiteto, o desenvolvedor, o segurança e o proprietário dos requisitos de negócios concordem claramente quem valida os dados, quem assina a precisão, quem é responsável pelo monitoramento de incidentes. Sem isso, a governança se transforma em um jogo de um gol.
Cultura “E se”.
Eu peguei isso da análise de sistemas. Equipes fortes fazem perguntas a si mesmas durante o projeto: “E se nosso modelo começar a gerar conselhos sobre autotratamento? E se for enganado através da injeção de prompt? E se começar a discriminar por gênero?” E não apenas perguntam, mas projetam proteção contra esses cenários. Isso não é paranoia — é higiene arquitetônica.
Transparência para o usuário.
Em produtos B2C, agora considero uma boa forma de rotular honestamente o conteúdo gerado por IA e dar ao usuário a oportunidade de recusar decisões automáticas. Isso reduz os riscos legais e, estranhamente, aumenta a confiança. Testamos: as pessoas são mais leais a um serviço que não tenta fingir ser humano.
Conclusão: o arquiteto é um estrategista, não um supervisor
Quando comecei a entender a Governança de IA, parecia que era um conjunto de restrições que impediam a construção rápida de recursos. Agora, eu o percebo como parte do pensamento arquitetônico. Se seu sistema inclui componentes não determinísticos como LLMs, você simplesmente deve projetar loops de controle. Não é sobre o medo dos reguladores — é sobre responsabilidade profissional.
O caso da Air Canada é uma ilustração perfeita de como a ausência desses loops leva a perdas específicas e precedentes judiciais. Mas eu gosto ainda mais quando a governança bem construída ajuda a equipe a dormir em paz e se concentrar em tarefas de produto, e não em incidentes noturnos.
Se o tema da Governança de IA já deixou de ser abstrato para você e começou a se transformar em uma tarefa de trabalho, você pode continuar a análise na aula aberta da OTUS
“Critérios de qualidade e segurança dos sistemas de IA no produto”
. Será realizado
19 de maio às 20:00
no âmbito do curso
“Estratégia e gerenciamento de IA na empresa”
. Vamos falar sobre como avaliar a qualidade e a segurança dos sistemas de IA, onde colocar os pontos de controle e como construir a governança sem burocracia desnecessária, mas com responsabilidade de engenharia normal.
➡ Inscreva-se na aula aberta
➡ Mais informações sobre o curso
Assine o blog OTUS
— aqui analisamos IA, arquitetura e práticas de engenharia com referência a tarefas reais das equipes.
📤 Compartilhar & Baixar
🧰 Ferramentas recomendadas
Divulgação: alguns links são patrocinados. Podemos receber comissão se você comprar — sem custo extra para você. Só indicamos o que faz sentido para a comunidade.
