Este curso trata da avaliação de um sistema de IA antes da compra, permitindo que o implementador tome uma decisão de aquisição fundamentada e defensável. Ele se baseia no EU AI Act (Lei de IA da UE) como principal marco jurídico e considera as equipes de compras e de compliance como as responsáveis por decidir o que exigir e o que recusar. Muitas equipes tratam a compra de IA como a compra de software convencional, focando na demonstração e na análise de segurança como as etapas mais desafiadoras. No entanto, o verdadeiro desafio é avaliar o comportamento do sistema durante o uso real, uma vez que seus resultados podem variar conforme os prompts, os dados e o contexto. Essa variação pode passar despercebida, pois o fornecedor ainda consegue apresentar um fluxo de trabalho impecável. Cabe ao comprador determinar quais evidências são suficientes.
Neste curso, define-se sistema de IA como um software que gera resultados — como textos, pontuações, recomendações ou decisões — a partir de dados de entrada, sendo que tais resultados podem influenciar as ações subsequentes das pessoas. Esse aspecto é relevante para o processo de compras, pois uma mesma funcionalidade pode ter baixo impacto em um cenário de uso e alto impacto em outro, dependendo de quem é afetado pelos resultados e de como eles são utilizados. O trabalho ocorre em etapas cotidianas, como a análise da documentação do fornecedor, a aprovação de um caso de uso e o estabelecimento de condições para a implementação. A complexidade aumenta quando a questão não é apenas se o sistema funciona, mas também o que ele poderia realizar em nosso contexto específico — algo que a demonstração inicial não revelou. Visualizar todo o fluxo de trabalho antecipadamente é útil, pois cada verificação corresponde a um momento específico do processo de compra. A seguir, apresentamos uma visão geral desse fluxo.
Uma ferramenta de software convencional geralmente executa a mesma ação para a mesma entrada de dados; portanto, é possível testá-la uma única vez e definir o resultado como requisito. Um sistema de IA pode apresentar disponibilidade constante e, ainda assim, gerar conteúdos inconsistentes, pois ele cria ou infere resultados em vez de seguir regras fixas. Isso significa que não se pode confiar apenas em um teste de aceitação para garantir o desempenho no uso contínuo, mesmo que o fornecedor afirme que a solução está pronta para produção. É necessário vincular a avaliação ao uso específico pretendido, levando em conta quem lerá o resultado e qual ação ele poderá desencadear. [fontes][/fontes]
Uma armadilha comum nas compras corporativas é tratar o modelo como se fosse o produto, quando, na verdade, o produto é todo o sistema que o cerca. Esse sistema engloba a interface do usuário, os prompts (comandos), a recuperação de informações de seus documentos, as integrações e quaisquer etapas de revisão humana. Esses componentes determinam o fluxo e o destino dos dados, bem como o que é registrado. Eles também definem a facilidade com que erros podem ser detectados antes de chegarem a um cliente, candidato ou funcionário. [fontes][/fontes]
As áreas de compras e compliance não precisam ser responsáveis pela implementação técnica para realizar uma due diligence eficaz. A decisão de compra e as condições estabelecidas são de sua responsabilidade; portanto, você pode exigir documentos comprobatórios e respostas claras antes de assinar o contrato. Embora as equipes de Produto e TI geralmente cuidem dos detalhes de integração e a área de privacidade foque na proteção de dados, você pode solicitar a cada uma delas informações concretas que embasem a decisão de compra. O segredo é fazer perguntas que gerem documentos, e não apenas garantias verbais. [fontes][/fontes]
Uma divisão de trabalho útil consiste em separar as alegações do fornecedor, as confirmações de suas equipes internas e as observações feitas durante um teste piloto. As alegações do fornecedor geralmente constam em fichas técnicas, relatórios de segurança ou manuais de instrução. As confirmações internas aparecem em notas de integração, minutas de procedimentos operacionais ou aprovações de risco. Já as observações são registradas em relatórios de testes, anotações de equipes de segurança (red teams) e capturas de tela que mostram como o sistema processou seus comandos e dados. [fontes][/fontes]
Essa verificação só vale a pena se alterar o foco da sua atenção nas etapas seguintes. Um mesmo sistema pode parecer seguro em uma demonstração, mas levantar preocupações imediatas assim que se define o caso de uso e as pessoas afetadas. Identifique a principal preocupação que surgiria em cada cenário, pois é ela que orientará a próxima solicitação feita ao fornecedor. [fontes][/fontes]