O Processo de Compras É o Sistema de Governança

Por Heather Grizzle, Novara Consulting Group

Resumo Executivo

A governança de inteligência artificial é cada vez mais expressa por meio de políticas, comitês, princípios, inventários e classificações de risco. Essas estruturas são importantes. Mas quando uma instituição pública efetivamente adquire e implementa um sistema de IA, a governança eventualmente precisa se tornar algo muito menos abstrato. Precisa se tornar um registro.

Alguém tem que descrever o que o sistema tem permissão para fazer. Alguém tem que decidir quais evidências são suficientes para sustentar as alegações do fornecedor. Alguém tem que identificar as pessoas que podem ser prejudicadas quando o sistema falha. Alguém tem que determinar quais falhas exigem intervenção humana, quais mudanças exigem reavaliação e quais condições exigem que o sistema seja suspenso. Se essas decisões não forem documentadas antes da implementação, uma política de governança de IA não corrige a omissão. O processo de compras é onde os princípios institucionais se tornam compromissos operacionais.

A Governança Eventualmente Precisa Alcançar a Transação

Uma contingência só é uma salvaguarda se a pessoa que dela precisa puder realmente utilizá-la.

Heather Grizzle

As organizações estão construindo estruturas de governança de IA cada vez mais sofisticadas. Elas estabelecem princípios de IA responsável, criam comitês de revisão, mantêm inventários e classificam sistemas de acordo com o risco. Adotam políticas que exigem justiça, transparência, responsabilização, privacidade, acessibilidade e supervisão humana. Então começa o processo de compras. Um fornecedor responde a uma solicitação. Demonstrações de produto são agendadas. Documentação de acessibilidade é coletada. Questionários de segurança são preenchidos. Termos jurídicos são negociados. Os responsáveis pelo negócio descrevem as eficiências que esperam. A tecnologia passa pelos portões estabelecidos pela instituição e entra em operação.

A existência desses portões pode gerar considerável confiança institucional, mas confiança não é o mesmo que uma decisão defensável. A questão crítica de governança não é apenas se o sistema passou pelo processo exigido. É se o registro resultante contém as evidências necessárias para justificar a implementação específica que foi aprovada.

Essa distinção se torna especialmente importante quando a IA medeia o acesso para pessoas com deficiência. Um sistema pode resumir informações, comunicar-se com pacientes, avaliar candidatos, traduzir idiomas, gerar material instrucional, priorizar casos, auxiliar funcionários, autenticar usuários, responder perguntas ou, cada vez mais, agir em nome de uma instituição. Em cada caso, a acessibilidade não é simplesmente uma característica da interface. É parte da arquitetura de decisão. Uma pessoa com deficiência pode encontrar um sistema de forma diferente da população para a qual ele foi primariamente projetado, testado ou validado, e uma falha de acessibilidade pode alterar as informações que essa pessoa recebe, as opções disponíveis para ela, sua capacidade de responder, ou a interpretação da instituição sobre seu comportamento. O registro de compras, portanto, precisa estabelecer mais do que se a acessibilidade foi considerada. Precisa estabelecer o que foi considerado, o que foi testado, o que permanece desconhecido e o que a instituição decidiu fazer em relação à incerteza.

O Processo de Compras como Instrumento de Responsabilização

Os processos de compras costumam ser entendidos principalmente como registros administrativos. Para a IA, devem ser cada vez mais entendidos como instrumentos de governança. Um registro maduro de compras de IA deve permitir que um revisor independente reconstrua o raciocínio da instituição sem depender da memória institucional das pessoas que participaram da compra. Isso significa que o registro deve responder a várias perguntas:

1. O que exatamente o sistema foi comprado para fazer?
2. O que ele foi explicitamente proibido de fazer?
3. Quais populações se esperava que o encontrassem?
4. Que evidências sustentaram as alegações utilizadas na aprovação, e quem produziu essas evidências?
5. Quais limitações eram conhecidas, e quais limitações permaneciam desconhecidas?
6. O que acontecia quando o sistema estava incerto ou errado?
7. Quem detinha autoridade para anulá-lo?
8. Como uma pessoa afetada poderia contestar sua saída?
9. O que levaria a instituição a reconsiderar a implementação?
10. Quem tinha autoridade para interrompê-lo?

Essas não são perguntas para a investigação de incidentes após uma falha. São perguntas de compras.

1. Uso Pretendido e Uso Proibido

O primeiro requisito é enganosamente simples: definir o que a instituição está comprando. Sistemas de IA são frequentemente adquiridos por meio de descrições amplas de capacidade. Um sistema pode ser descrito como assistente, tradutor, ferramenta de acessibilidade, sistema de apoio à decisão, chatbot, agente, ferramenta de triagem ou plataforma de produtividade. Esses rótulos são especificações de governança inadequadas. O registro de compras deve identificar a função institucional real.

Uma ferramenta de comunicação usada para ajudar alguém a navegar em um site apresenta um risco diferente da mesma tecnologia usada durante uma triagem médica. Um sistema automatizado de transcrição usado para gerar atas de reunião apresenta um risco diferente de um usado para criar o registro oficial de um processo disciplinar. Um sistema de reconhecimento de língua de sinais usado experimentalmente por um indivíduo não é equivalente a um que uma instituição apresenta como substituto de outro meio de acesso à comunicação. A mesma tecnologia pode, portanto, transitar entre categorias de risco sem qualquer mudança em seu modelo subjacente, porque o contexto de implementação mudou.

2. Análise da População Afetada

A aquisição tradicional de tecnologia pergunta quem usará o sistema. A governança de IA também deve perguntar quem será afetado por ele, e essas populações não são necessariamente as mesmas. Um funcionário pode operar um sistema de IA enquanto um paciente, estudante, candidato, residente, cliente ou beneficiário de assistência experimenta suas consequências. Pessoas com deficiência podem ser especialmente difíceis de identificar por meio da análise convencional de usuários, porque a deficiência frequentemente altera o caminho por meio de um sistema, em vez da categoria nominal de usuário.

O registro de compras deve, portanto, identificar interações previsíveis de acessibilidade. O sistema processa fala? Ele gera ou interpreta linguagem? Ele depende de visão, audição, destreza, cognição, tempo de resposta, características biométricas ou um modo particular de comunicação? Ele infere intenção ou competência a partir de comportamento que a deficiência pode afetar? Uma saída inacessível altera a capacidade de uma pessoa de participar de uma decisão subsequente? Essas perguntas convertem a acessibilidade de um artefato de conformidade em uma investigação de risco do sistema.

3. O Registro das Alegações do Fornecedor

Toda alegação relevante do fornecedor utilizada durante o processo de compras deve ter um status evidencial. Nem toda alegação exige teste independente, mas as instituições devem distinguir entre pelo menos três categorias. Uma capacidade é alegada quando o fornecedor afirma que ela existe. É demonstrada quando evidências mostram que foi observada sob condições especificadas. É estabelecida para implementação quando evidências sustentam razoavelmente a confiança nela no contexto pretendido da instituição. Essas categorias não são intercambiáveis.

Uma demonstração pode estabelecer que um sistema é capaz de produzir uma saída. Não estabelece necessariamente com que confiabilidade ele produz essa saída em diferentes populações, ambientes ou casos de uso relevantes. Da mesma forma, a documentação pode estabelecer o que um fornecedor representa sobre seu sistema. Não pode estabelecer independentemente que a representação está correta. O processo de compras deve preservar essa distinção. Caso contrário, afirmações gradualmente se tornam constatações simplesmente por terem sido repetidas em documentos suficientes.

Estabelecida para implementação

Um status de alegação do fornecedor que significa que a evidência sustenta razoavelmente a confiança na capacidade no contexto real e pretendido da instituição, e não apenas que a capacidade foi observada sob condições de demonstração.

4. Garantia Independente

As evidências fornecidas pelos fornecedores desempenham um papel legítimo na contratação. Os fornecedores conhecem os seus sistemas melhor do que os compradores e deve-se esperar que divulguem testes, arquitetura, limitações, condições de falha conhecidas e evidências de desempenho relevantes. Mas a relação comercial importa. A parte que busca o contrato não deve ser a única parte a determinar se as evidências são suficientes para concedê-lo.

Garantia independente não significa recriar o programa de engenharia do fornecedor. Significa testar as alegações que importam para a decisão de contratação em condições capazes de refutá-las. Para IA relacionada à acessibilidade, isso pode exigir avaliação com a participação de pessoas com a deficiência relevante e, quando envolver acesso linguístico, membros qualificados da comunidade linguística. O objetivo não é uma participação cerimonial. É autoridade probatória. As pessoas capazes de identificar uma falha consequente devem dispor de um mecanismo para que essa falha afete a decisão de contratação. Caso contrário, há participação sem governança.

5. Falha e Arquitetura de Contingência

Toda contratação de IA deve conter uma resposta escrita a uma única pergunta: o que acontece quando o sistema não funciona? “Humano no circuito” não é uma resposta adequada. O registro deve identificar o humano, o gatilho, a autoridade, o tempo de resposta e o caminho alternativo disponível para a pessoa afetada.

Para usuários com deficiência, a própria contingência também deve ser acessível. Um sistema de comunicação por IA que falha e direciona uma pessoa Surda a fazer uma ligação telefônica não produziu uma contingência. Um processo digital automatizado que se torna inacessível e exige que um usuário cego conclua a mesma interface inacessível não transferiu a pessoa para supervisão humana de forma significativa.

Uma contingência só é uma salvaguarda se a pessoa que dela precisa puder realmente utilizá-la.

Heather Grizzle

6. Limites de Desempenho e Incertezas Conhecidas

Os documentos de contratação tendem a registrar o que os produtos conseguem fazer. Os registros de governança também precisam declarar onde a confiança termina. O desempenho da IA é condicional. Pode variar conforme idioma, dialeto, sotaque, estilo de sinalização, iluminação, posição da câmera, deficiência, dispositivo, ambiente, terminologia de domínio, duração da interação, características demográficas, ou inúmeras outras variáveis. As instituições devem exigir que os fornecedores divulguem os limites de desempenho conhecidos e devem documentar separadamente as áreas que não foram avaliadas.

Essa distinção importa. “Não avaliado” não é a mesma constatação que “falhou”, mas também não é a mesma constatação que “seguro”. A incerteza não é um defeito na contratação se for reconhecida e governada. A incerteza não documentada, sim.

7. Registro, Rastreabilidade e Reconstrução

Quando uma interação mediada por IA causa dano, a instituição deve ser capaz de reconstruir o que aconteceu, e isso exige decisões sobre o registro de dados antes da implantação. Qual versão do sistema estava em operação? Quais entradas foram recebidas? Qual saída foi gerada? A saída foi modificada? Um humano a revisou? Que informação esse revisor viu? Que ação se seguiu? A instituição consegue reproduzir o evento sem reter dados que nunca deveriam ter sido retidos em primeiro lugar?

Rastreabilidade e privacidade podem criar exigências legitimamente conflitantes. Esse conflito deve ser resolvido por meio do design do sistema e da governança, em vez de ser descoberto durante um litígio, uma reclamação de acessibilidade ou uma investigação interna. O arquivo de contratação deve documentar a resolução.

8. Reclamação, Contestabilidade e Reparação

Uma pessoa afetada pela IA precisa de mais do que um mecanismo para relatar um problema técnico. Ela pode precisar contestar o que a instituição fez por causa do sistema, e isso é uma função diferente. Se um sistema de IA traduz incorretamente uma comunicação, caracteriza o comportamento de forma errada, produz informação inacessível, gera uma inferência falsa ou contribui para uma ação institucional adversa, a pessoa afetada precisa de um caminho para contestar a decisão resultante.

A instituição deve saber antes da implantação quem recebe a contestação, quem a investiga, quais evidências são preservadas, se a saída de IA contestada permanece em vigor durante a revisão, quais reparações estão disponíveis e com que rapidez a instituição deve responder.

9. Alteração do Modelo e Revalidação

A contratação de IA cria um problema que os contratos de software tradicionais não foram concebidos para lidar particularmente bem: o produto que foi avaliado pode não permanecer o produto que é implantado. Os modelos são atualizados. As salvaguardas mudam. Os dados de treinamento mudam. As interfaces mudam. As dependências de terceiros mudam. Os fornecedores substituem os modelos subjacentes. O desempenho pode melhorar em um domínio e piorar em outro sem que a instituição compradora inicie qualquer alteração por si mesma.

O arquivo de contratação precisa, portanto, de uma regra de controle de mudanças. A questão relevante não é se o fornecedor tem permissão para atualizar o seu produto. É quais alterações invalidam as evidências nas quais a instituição se baseou. Os contratos devem identificar alterações materiais que exijam notificação, reavaliação, novos testes de aceitação ou aprovação antes do uso continuado em contextos especificados. Caso contrário, uma instituição pode realizar uma garantia rigorosa no momento da aquisição e, ainda assim, encontrar-se governando um sistema materialmente diferente seis meses depois, usando evidências produzidas para o sistema anterior.

10. Autoridade de Suspensão e Saída

Governança sem autoridade para interromper é meramente consultiva. Alguém dentro da instituição deve ter autoridade para restringir, suspender ou encerrar uma implantação de IA quando as evidências já não sustentarem o seu uso, e as condições desencadeadoras não deveriam precisar ser inventadas durante uma crise.

O registro de contratação deve identificar tanto os gatilhos quanto a autoridade decisória.

Deve também abordar a saída. Quem detém ou recebe os dados institucionais quando a relação termina? Quais registros devem ser retidos? O que deve ser excluído? Como a instituição restabelece o caminho de serviço anterior? O que acontece com as pessoas que passaram a depender do processo mediado por IA? O planejamento de saída não é apenas gestão de fornecedores. É planejamento de continuidade de acesso.

Da Política de IA à Evidência Institucional

O desafio emergente para a governança da IA não é a escassez de princípios. É a tradução. A equidade precisa tornar-se um critério de avaliação. A transparência precisa tornar-se um requisito de divulgação. A supervisão humana precisa tornar-se uma autoridade designada. A acessibilidade precisa tornar-se uma condição de implantação. A responsabilização precisa tornar-se um órgão nomeado e uma reparação documentada. O monitoramento precisa tornar-se um gatilho para ação. E a IA responsável eventualmente precisa tornar-se algo que um responsável pela contratação possa arquivar.

Isso é particularmente importante em instituições públicas porque a contratação é onde compromissos institucionais abstratos encontram dinheiro, contratos, fornecedores, deveres legais e pessoas que não podem simplesmente escolher outro governo, escola, hospital, tribunal ou serviço público quando a tecnologia não funciona para elas. O arquivo de contratação, portanto, desempenha uma função muito maior do que o registro documental. Ele estabelece a teoria de risco aceitável da instituição.

Posição Política da NCG

A Novara Consulting Group sustenta que os sistemas de IA que afetam pessoas com deficiência não devem ser aprovados apenas por terem satisfeito o processo geral de governança de IA de uma organização. O registro de contratação deve conter evidências suficientes para reconstruir e defender a decisão específica de implantação.

O padrão não é conhecimento perfeito. Nenhum processo de aquisição pode eliminar a incerteza. O padrão é a incerteza governada: saber o que foi estabelecido, o que não foi, que evidência justificou avançar mesmo assim, e quem assume a responsabilidade pela decisão.

Posição Final

Após uma falha de IA, as instituições frequentemente perguntam se o fornecedor deveria ter avisado. Por vezes a resposta será sim. Mas a responsabilização pública exige outra pergunta: que evidência exigiu a instituição antes de concordar em avançar? Essa pergunta não pode ser delegada. O fornecedor pode fornecer evidência. Um avaliador pode avaliá-la. Um comité pode aconselhar. As partes interessadas com deficiência podem identificar falhas que outros não conseguem ver. Os advogados podem negociar a distribuição do risco contratual. A instituição continua a tomar a decisão, e o seu registo de aquisição deve provar que sabia que decisão estava a tomar.

Um sistema de IA não é governado porque uma organização tem uma política de IA. É governado quando a instituição consegue demonstrar por que razão este sistema, para este propósito, afetando estas pessoas, nestas condições, foi autorizado a funcionar.

Heather Grizzle

É no processo de aquisição que essa responsabilização começa.