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

Vendor evidence has a legitimate role in procurement. Vendors know their systems better than purchasers do and should be expected to disclose testing, architecture, limitations, known failure conditions, and relevant performance evidence. But the commercial relationship matters. The party seeking the contract should not be the only party determining whether the evidence is sufficient to award it.

Independent assurance does not mean recreating the vendor’s engineering program. It means testing the claims that matter to the purchasing decision under conditions capable of disproving them. For accessibility-related AI, this may require evaluation involving people with the relevant disability and, where linguistic access is involved, qualified members of the language community. The objective is not ceremonial participation. It is evidentiary authority. The people capable of identifying a consequential failure must have a mechanism for causing that failure to affect the procurement decision. Otherwise, participation exists without governance.

5. Failure and Fallback Architecture

Every AI procurement should contain a written answer to a single question: what happens when the system does not work? “Human in the loop” is not an adequate answer. The record should identify the human, the trigger, the authority, the response time, and the alternative pathway available to the affected person.

For disabled users, the fallback itself must also be accessible. An AI communication system that fails and directs a Deaf person to make a telephone call has not produced a fallback. An automated digital process that becomes inaccessible and requires a blind user to complete the same inaccessible interface has not transferred the person to human oversight in any meaningful sense.

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

Heather Grizzle

6. Performance Boundaries and Known Unknowns

Procurement documents tend to record what products can do. Governance records also need to state where confidence ends. AI performance is conditional. It may vary according to language, dialect, accent, signing style, lighting, camera position, disability, device, environment, domain terminology, interaction length, demographic characteristics, or countless other variables. Institutions should require vendors to disclose known performance boundaries and should separately document areas that have not been evaluated.

That distinction matters. Not evaluated is not the same finding as failed, but it is also not the same finding as safe. Uncertainty is not a procurement defect if it is recognized and governed. Undocumented uncertainty is.

7. Logging, Traceability, and Reconstruction

When an AI-mediated interaction produces harm, the institution should be able to reconstruct what happened, and that requires decisions about logging before deployment. What system version was operating? What inputs were received? What output was generated? Was the output modified? Did a human review it? What information did that reviewer see? What action followed? Can the institution reproduce the event without retaining data that should never have been retained in the first place?

Traceability and privacy can create legitimate competing requirements. That conflict should be resolved through system design and governance rather than discovered during litigation, an accessibility complaint, or an internal investigation. The procurement file should document the resolution.

8. Complaint, Contestability, and Redress

A person affected by AI needs more than a mechanism for reporting a technical problem. They may need to contest what the institution did because of the system, and that is a different function. If an AI system mistranslates communication, incorrectly characterizes behavior, produces inaccessible information, generates a false inference, or contributes to an adverse institutional action, the affected person needs a pathway to challenge the resulting decision.

The institution should know before deployment who receives the challenge, who investigates it, what evidence is preserved, whether the contested AI output remains operative during review, what remedies are available, and how quickly the institution must respond.

9. Model Change and Revalidation

AI procurement creates a problem that traditional software contracts were not designed to handle particularly well: the product that was evaluated may not remain the product that is deployed. Models are updated. Guardrails change. Training data changes. Interfaces change. Third-party dependencies change. Vendors replace underlying models. Performance can improve in one domain and degrade in another without the purchasing institution initiating any change itself.

The procurement file therefore needs a change-control rule. The relevant question is not whether the vendor is permitted to update its product. It is which changes invalidate the evidence on which the institution relied. Contracts should identify material changes requiring notice, reevaluation, renewed acceptance testing, or approval before continued use in specified contexts. Otherwise, an institution can perform rigorous assurance at acquisition and still find itself governing a materially different system six months later using evidence produced for the previous one.

10. Suspension and Exit Authority

Governance without stop authority is advisory. Someone within the institution must have the authority to restrict, suspend, or terminate an AI deployment when evidence no longer supports its use, and the triggering conditions should not have to be invented during a crisis.

The procurement record should identify both the triggers and the decision authority.

It should also address exit. Who owns or receives institutional data when the relationship ends? What records must be retained? What must be deleted? How does the institution restore the previous service pathway? What happens to people who have become dependent on the AI-mediated process? Exit planning is not merely vendor management. It is continuity-of-access planning.

From AI Policy to Institutional Evidence

The emerging challenge for AI governance is not a shortage of principles. It is translation. Fairness has to become an evaluation criterion. Transparency has to become a disclosure requirement. Human oversight has to become an assigned authority. Accessibility has to become a deployment condition. Accountability has to become a named office and a documented remedy. Monitoring has to become a trigger for action. And responsible AI eventually has to become something a procurement officer can place in a file.

This is particularly important in public institutions because procurement is where abstract institutional commitments encounter money, contracts, vendors, statutory duties, and people who cannot simply choose another government, school, hospital, court, or public service when the technology does not work for them. The procurement file therefore performs a function much larger than recordkeeping. It establishes the institution’s theory of acceptable risk.

NCG Policy Position

Novara Consulting Group holds that AI systems affecting disabled people should not be approved solely because they have satisfied an organization’s general AI governance process. The procurement record should contain sufficient evidence to reconstruct and defend the specific deployment decision.

The standard is not perfect knowledge. No procurement process can eliminate uncertainty. The standard is governed uncertainty: knowing what has been established, what has not, what evidence justified proceeding anyway, and who bears responsibility for the decision.

Closing Position

After an AI failure, institutions often ask whether the vendor should have warned them. Sometimes the answer will be yes. But public accountability requires another question: what evidence did the institution require before it agreed to proceed? That question cannot be outsourced. The vendor can supply evidence. An assessor can evaluate it. A committee can advise. Disabled stakeholders can identify failures that others cannot see. Lawyers can negotiate the allocation of contractual risk. The institution still makes the decision, and its procurement record should prove that it knew what decision it was making.

An AI system is not governed because an organization has an AI policy. It is governed when the institution can show why this system, for this purpose, affecting these people, under these conditions, was permitted to operate.

Heather Grizzle

The procurement file is where that accountability begins.