O setor público precisa de uma contratação pública que saiba dizer não.

Uma autoridade pública não se torna responsável por assinar um sistema de IA. Torna-se responsável quando os seus requisitos, provas, autoridade humana,...

O setor público precisa de uma contratação pública que saiba dizer não.

The document that can end a purchase

A public procurement file often begins with a request that sounds harmless: find a system that can help with a task. The request moves through a problem statement, a market consultation, a set of requirements, an evaluation, a contract and, if the process is healthy, a decision that can still stop the work. That last possibility is easy to lose. Once money, calendars and political attention have gathered around a purchase, the word no starts to sound like a failure of delivery. In public work, it can be the most useful decision in the file.

European procurement law already treats a tender as more than a contest of attractive promises. Directive 2014/24/EU says that award criteria must allow effective and fair competition and must be accompanied by arrangements that let the contracting authority verify the information supplied by tenderers. The directive also says that criteria should not give the authority unrestricted freedom of choice. A public buyer has to describe what matters, explain how it will be weighed and check whether the offer actually meets it. This is not an administrative footnote. It is the legal shape of a decision that other people must be able to understand and challenge.

AI makes the old discipline harder because a supplier can offer a system whose behaviour depends on data, model updates, prompts, thresholds, integrations, people and a service that may change while the contract is still warm. The brochure can remain the same while the thing behind it moves. A procurement team therefore has to buy more than an interface. It has to buy a bounded capability, the evidence that the capability is suitable, the authority to supervise it and a credible way to stop or replace it.

The public sector needs procurement that can say no because the public sector cannot outsource its judgement. A supplier may provide a model, a workflow, a hosted service or a set of tools. It cannot provide the legitimacy of the decision made with them. The authority still has to know what problem it is solving, whose interests may be affected, what evidence supports the system, which person can intervene and how the service will continue if the supplier changes course. A signature is not a transfer of responsibility. It is a record that responsibility has been arranged.

This article follows that arrangement from the first sentence of a requirement to the last line of an exit record. It uses European public guidance and procurement material as evidence. The practical patterns are recommendations, not claims that every authority must use one form. Any invented situation is labelled as hypothetical. A plausible office, a neat tender and a dramatic failure are not evidence merely because they fit a familiar story.

A public buyer buys a promise twice

Every public purchase carries two promises. The first is the supplier’s promise about a product or service. The second is the authority’s promise to the people who depend on the work: that the money was spent for a defined public purpose, that the decision can be explained, that relevant rights were considered and that someone remains answerable when the system is wrong. The second promise is the one that survives the launch event.

AI procurement often makes the first promise vivid and the second one vague. A demonstration can show a fluent summary, a ranked list or a fast answer. It rarely shows who may reject the output, what happens when a source is missing, how a change is approved, whether the records can be exported, or which person can pause the service without negotiating their own authority in the middle of an incident. Those questions are less cinematic. They are also the questions that decide whether a public body can remain in charge.

A Comunidade de Compradores Públicos da Comissão Europeia descreve as suas cláusulas contratuais-modelo atualizadas para a IA em três partes: uma versão completa para IA de risco elevado alinhada com o Regulamento IA, uma versão ligeira personalizável para IA que não seja de risco elevado e comentários sobre como utilizar e adaptar as cláusulas. A distinção é importante. Uma cláusula-modelo não é um carimbo mágico que torna um procedimento de aquisição adequado. É um ponto de partida para repartir obrigações entre uma organização pública e um fornecedor, num contrato cujo âmbito, finalidade e provas ainda têm de ser decididos pelo comprador.

Um comprador deve, por isso, perguntar o que está realmente a prometer ao público antes de perguntar o que um fornecedor consegue demonstrar. Estará a autoridade a prometer um caminho mais rápido para reduzir um atraso, uma primeira análise mais consistente, uma inspeção mais segura, um melhor aproveitamento de conhecimentos especializados escassos ou apenas uma experiência cujos limites são visíveis? Cada finalidade cria provas diferentes e razões diferentes para parar. Um sistema que redige notas internas pode precisar de uma fronteira de autoridade diferente da de um sistema que classifica candidaturas para um serviço que as pessoas não podem evitar.

Considere uma equipa de avaliação hipotética a analisar uma ferramenta que resume submissões de fornecedores. A equipa pode decidir que a tarefa é adequada para assistência, mas apenas se o resumo preservar exclusões, condições e datas e remeter os revisores para as passagens originais. Se o fornecedor não conseguir demonstrar como esses requisitos serão testados, a equipa deve poder recusar a ferramenta ou restringir o contrato. Isso não é uma acusação contra o fornecedor. É uma conclusão sobre as provas disponíveis para a finalidade definida.

O mesmo raciocínio aplica-se quando o problema é atraente mas mal delimitado. Um organismo público pode querer prever a procura, priorizar inspeções ou encaminhar correspondência. Esses verbos escondem as decisões subjacentes. O que conta como procura. O que a prioridade altera. Que correspondência pode ser encaminhada com segurança sem que uma pessoa a leia. O primeiro não pode ser dirigido ao âmbito do problema, e não à utilização de software. Recusar uma aquisição pouco clara é muitas vezes a forma de uma autoridade proteger a parte útil do trabalho de uma parte que não pode ser testada.

Escreva o problema antes da solução

A aquisição torna-se frágil quando uma categoria de produto chega antes de um problema público ter sido nomeado. A inteligência artificial é especialmente boa a criar esta ordem porque o mesmo modelo pode ser apresentado como assistente de escrita, classificador, camada de pesquisa ou agente, consoante o diapositivo. A autoridade precisa de descrever o trabalho em termos que permaneçam significativos quando o fornecedor, a família de modelos e a interface forem removidos.

O Algoritmekader neerlandês, mantido para organizações públicas, coloca este trabalho entre as suas medidas recomendadas. Pede às organizações que descrevam a finalidade pretendida e os dados utilizados, determinem o grupo de risco aplicável, estabeleçam o impacto se o algoritmo não funcionar como pretendido e decidam se uma solução deve ser desenvolvida ou comprada. Aponta também para uma arquitetura de arranque de projeto para desenvolver ou adquirir algoritmos. Não são decorações de aquisição. São formas de tornar o problema legível antes de ser oferecida uma resposta.

Um bom requisito começa pela decisão ou serviço que deve melhorar, pelas pessoas que o executam ou recebem, pela informação que o sistema pode utilizar, pela informação que não pode utilizar e pela autoridade humana que permanece. Estabelece as condições em que o sistema é útil e as condições em que não deve ser utilizado. Nomeia os registos que precisam de existir quando o resultado é aceite, rejeitado, corrigido ou escalado. Não precisa de prever o design interno do fornecedor. Precisa de definir a capacidade pública que pode ser inspecionada.

É aqui que os requisitos funcionais e de desempenho são importantes. A Diretiva 2014/24/UE exige que as especificações técnicas sejam suficientemente precisas para que os concorrentes compreendam o objeto do contrato e para que as autoridades avaliem de que forma as propostas cumprem os critérios. Um requisito como «fornecer uma solução inteligente» não é um teste útil. Um requisito como «preservar as passagens de origem utilizadas num rascunho, mostrar a data de recuperação, permitir que um revisor rejeite o rascunho e exporte o registo resultante» está mais próximo de uma necessidade pública testável. Descreve um comportamento e um percurso de evidência, e não uma moda.

Os requisitos devem também expor o limite da tarefa. Uma autoridade pública pode afirmar que um sistema pode sugerir um percurso, mas não pode tomar a decisão final. Pode declarar que uma recomendação não deve ser utilizada quando uma fonte especificada está ausente ou é contraditória. Pode exigir um percurso humano para uma pessoa afetada que pretenda contestar o resultado. Estas não são restrições hostis. São as condições sob as quais a aquisição permanece um serviço público e não um fluxo de trabalho privado com um logótipo governamental.

Uma declaração de problema restrita não é falta de ambição. É uma forma de tornar a ambição responsabilizável. Se a autoridade não conseguir explicar que passo o sistema altera, quem beneficia, o que pode correr mal e o que uma pessoa pode fazer a seguir, não está pronta para comparar fornecedores. A ação correta pode ser mais exploração, uma solução sem IA, um pequeno piloto controlado ou nenhuma aquisição de todo. O processo de aquisição deve ter espaço para cada uma destas respostas.

Transformar requisitos em evidência

A palavra evidência é utilizada de forma vaga na aquisição de tecnologia. Uma apresentação do fornecedor, uma demonstração do produto e uma declaração de que o sistema é fiável podem ser contributos úteis. Nenhum deles é automaticamente prova de que um requisito foi cumprido. A evidência tem de estar ligada a uma alegação, a um teste, a um âmbito e a uma pessoa que a possa inspecionar. Sem essa ligação, a avaliação torna-se uma competição em que vence a frase mais polida.

A diretiva relativa aos contratos públicos é clara quanto à relação básica: os critérios de adjudicação devem ser acompanhados de disposições que permitam verificar eficazmente as informações fornecidas pelos concorrentes. Este princípio é especialmente importante para a IA, porque um resultado pode parecer convincente enquanto as condições que o produziram permanecem ocultas. O comprador deve perguntar o que será mostrado, sob que condições de dados e de tarefa, com que referência, e como um revisor pode reproduzir ou contestar o resultado.

O Algoritmekader neerlandês faz a mesma exigência em linguagem prática. As suas medidas de contratação pública incluem tornar os requisitos de algoritmos parte dos documentos do procedimento e do contrato, exigir que os fornecedores apresentem evidência de que os requisitos são cumpridos como parte da avaliação, avaliar as condições de responsabilidade do fornecedor, exigir capacidade de auditoria no contrato, acordar o que acontece aos dados e artefactos, e pedir um plano para descontinuar o algoritmo. A lista é orientação, não uma lista de verificação jurídica universal. O seu valor reside em tratar a prova como um objeto de aquisição.

Um comprador pode separar a evidência em três categorias úteis. A evidência demonstrada é o que o fornecedor mostra numa avaliação controlada: a entrada, a saída, o tratamento de erros, a utilização de fontes e o percurso humano podem ser observados. A evidência inspecionável é o que a autoridade pode examinar sem depender de uma demonstração: documentação, resultados de testes, registos, interfaces, registos de alterações, descrições de dados e a capacidade de executar uma verificação acordada. A evidência contratual é o que o fornecedor deve continuar a fornecer: notificações de alterações materiais, informações sobre incidentes, acesso para auditoria, registos de serviço, facilidades de exportação e apoio a uma saída controlada. As categorias sobrepõem-se, mas impedem que uma sessão impressionante sustente todo o contrato.

As provas também precisam de um âmbito. Um fornecedor pode demonstrar que um sistema tem bom desempenho num conjunto de exemplos. O comprador continua a precisar de saber se os exemplos representam a língua pretendida, a qualidade documental, a mistura de casos, as necessidades de acessibilidade e as restrições operacionais. Uma afirmação sobre um modelo em laboratório não é automaticamente uma afirmação sobre um serviço público. É uma afirmação sobre a experiência que foi realizada. A equipa de contratação deve preservar a tarefa, as condições dos dados, a versão e o resultado para que a decisão posterior não fique desligada do teste.

Imagine, a título de hipótese, que um concorrente fornece um conjunto de amostras de resumos gerados e uma declaração geral de exatidão. A autoridade pode pedir os documentos de origem, a regra de seleção, a versão utilizada, o tratamento do material em falta, o procedimento de revisão e o artefacto que permanecerá após a aceitação. Se a resposta for que os detalhes são proprietários e não podem ser inspecionados, a equipa aprendeu algo importante. Não aprendeu que o sistema é mau. Aprendeu que o limite proposto para as provas pode ser demasiado fraco para o interesse público.

As provas devem ser proporcionais. Uma pequena ferramenta interna de apoio à redação não precisa do mesmo pacote de inspeção que um sistema que influencia o acesso a um serviço público. Proporcionalidade não significa aceitar um slogan em situações de baixo risco. Significa adequar a profundidade da prova à consequência, à reversibilidade, às pessoas afetadas e à capacidade de detetar e corrigir um erro. O fornecedor deve conhecer as provas exigidas antes de o concurso ser apresentado. Caso contrário, a autoridade está a alterar o concurso depois da corrida, o que é uma forma conhecida de produzir uma surpresa dispendiosa.

Um requisito deve conduzir a prova, e a prova deve poder alterar a decisão de adjudicação.

O comprador deve poder discordar

A responsabilização pública não é o mesmo que transparência do fornecedor. Um fornecedor pode explicar o seu serviço enquanto a autoridade continua sem uma via para um residente, trabalhador, empresa ou profissional contestar a forma como o serviço foi utilizado. O processo de contratação deve, por isso, perguntar como funciona a discordância, e não apenas como o sistema produz uma resposta.

O Algoritmekader coloca o controlo humano, os direitos fundamentais, a transparência e as vias de reclamação entre os seus temas do setor público. As medidas recomendadas incluem intervenção humana significativa na tomada de decisão, um processo através do qual os cidadãos ou outras partes interessadas podem apresentar uma reclamação, objeção ou recurso, uma decisão pública sobre a utilização do algoritmo e uma forma de publicar algoritmos com impacto no Registo de Algoritmos neerlandês. Estas medidas não transformam todos os algoritmos num espetáculo público. Tornam a responsabilidade da autoridade suficientemente visível para poder ser questionada.

Um requisito de aquisição sobre supervisão humana deve nomear a ação humana. Pode o revisor ver a informação que moldou a recomendação. Pode corrigir o registo. Pode rejeitar o resultado sem obter primeiro autorização do sistema. Pode pedir uma segunda via quando falta uma fonte. Pode interromper um lote, isolar uma versão ou escalar uma preocupação a alguém com autoridade. Se a resposta for apenas que uma pessoa está presente em algum ponto do processo, o requisito descreve mobiliário, não supervisão.

O desacordo também precisa de tempo. Um revisor a quem se espera que verifique todos os resultados mantendo a carga de trabalho original pode estar tecnicamente no circuito e praticamente fora dele. A aquisição pode exigir formação, apoio, provas utilizáveis e uma premissa de carga de trabalho para a revisão. Pode definir quais os casos que necessitam de aprovação prévia à ação e quais as ações reversíveis e de baixa consequência que podem avançar com registo e amostragem posterior. Pode pedir ao fornecedor que apoie a via em vez de a esconder atrás de uma interface de programação de aplicações.

A autoridade também tem de discordar do seu próprio entusiasmo. Um piloto bem-sucedido pode criar pressão para alargar uma ferramenta a uma população ou decisão que nunca fez parte do teste. O contrato deve preservar o propósito original e exigir uma nova decisão quando o propósito, os dados, as pessoas afetadas ou a consequência mudarem. Uma atualização não é automaticamente inofensiva por ser entregue como serviço. Uma nova utilização não está automaticamente coberta porque o mesmo logótipo aparece no topo do ecrã.

Quando um fornecedor afirma que o modelo é apenas consultivo, a autoridade deve olhar para o que o trabalho realmente faz. Se o pessoal for instruído a aceitar a ordenação, se não houver tempo para a rever ou se o sistema controlar quais os casos que chegam a uma pessoa, o conselho pode ter-se tornado uma decisão na prática. A equipa de aquisição não precisa de discutir o rótulo perfeito. Precisa de documentar o percurso do resultado até à consequência e manter a autoridade para alterar esse percurso.

Os limites do fornecedor fazem parte do contrato

A aquisição de IA é frequentemente descrita como uma escolha entre construir e comprar. A escolha mais difícil é como dividir o limite entre o fornecedor e a organização pública. O fornecedor pode controlar um modelo, serviço, via de atualização, infraestrutura, equipa de apoio e parte do processamento de dados. A autoridade controla o propósito público, a decisão, a população afetada e o dever de fornecer um serviço legal e utilizável. Um contrato deve ligar estas responsabilidades em vez de as deixar como dois diagramas educados.

As cláusulas contratuais modelo da UE para IA, atualizadas, são úteis porque reconhecem que os compradores públicos precisam de abordagens distintas para IA de alto risco e de risco não elevado e precisam de orientação sobre como personalizar as cláusulas na prática. Não substituem uma estratégia de aquisição ou uma revisão jurídica. São um vocabulário comum para tornar as responsabilidades explícitas. O comprador ainda tem de decidir quais as provas, direitos sobre dados, acesso a auditorias, aviso de alteração, apoio, responsabilidade e condições de saída que são proporcionais ao sistema adquirido.

Os dados e artefactos merecem atenção especial. Um sistema pode tocar em documentos-fonte, rótulos, instruções, incorporações, rascunhos gerados, correções humanas, conjuntos de avaliação, registos e registos finais. O contrato deve distinguir o que a autoridade fornece, o que o fornecedor cria, o que cada parte pode utilizar, o que deve ser devolvido, o que deve ser eliminado e que prova de eliminação ou retenção é exigida. Dizer que a autoridade é dona dos seus dados não responde onde vivem os artefactos derivados nem como a autoridade pode recuperar os registos que explicam um resultado.

Os direitos de auditoria precisam de uma forma prática. O comprador deve saber quais registos podem ser inspecionados, como é pedido o acesso, que aviso prévio é razoável, que proteções de confidencialidade se aplicam e o que acontece quando uma auditoria encontra uma lacuna. Uma cláusula de auditoria sem um caminho utilizável é uma sentença à espera de um litígio. O mesmo se aplica a uma cláusula de incidente que diz que o fornecedor cooperará sem nomear a informação, o prazo e o responsável necessários para a cooperação.

O controlo de alterações não deve ficar entregue às notas de versão. A autoridade pode exigir aviso prévio de uma alteração material ao modelo, fontes de dados, local de processamento, subcontratantes, interfaces, limiares, método de avaliação ou via humana. Pode definir que provas são necessárias antes de uma versão alterada ser utilizada para a tarefa pública. Pode exigir o direito de suspender, rejeitar ou reverter quando o serviço alterado deixar de cumprir um requisito material. Estas são recomendações para tornar o contrato operacional. Não são afirmações de que uma cláusula resolve todas as relações com fornecedores.

A responsabilidade inclui também o que o fornecedor não pode fornecer. Um serviço pode depender de um modelo ou infraestrutura de terceiros cujas alterações estão fora do controlo imediato do fornecedor. O comprador deve ser informado dessa dependência e deve saber quais obrigações lhe são transmitidas. Uma organização pública não pode avaliar uma cadeia inspecionando apenas a porta da frente. O contrato deve preservar um caminho para a prova relevante, ou o comprador deve reconhecer que a incerteza é uma razão para restringir ou recusar a compra.

Boas fronteiras protegem também os fornecedores. Um comprador público que pede todos os documentos possíveis, todos os detalhes do código-fonte e apoio ilimitado sem um propósito definido pode reduzir a concorrência e tornar o contrato pouco atrativo para fornecedores europeus mais pequenos. Proporcionalidade, clareza e um âmbito de prova credível permitem que um fornecedor diga o que pode fazer e que um comprador diga o que precisa. A contratação pública deve ser exigente sem ser teatral. Um muro feito de requisitos impossíveis afasta os maus sistemas e os bons com igual eficiência.

Alteração após a adjudicação continua a ser contratação pública

A adjudicação não é o fim da decisão. É o ponto em que o serviço entra num tipo diferente de escrutínio. Durante a operação, os dados mudam, as políticas alteram-se, as interfaces são substituídas, o pessoal aprende atalhos, os fornecedores revêem modelos e um sistema pode ser utilizado em situações que a equipa original não imaginou. A autoridade precisa de uma forma de notar estas alterações antes de se tornarem um novo propósito público por acidente.

O Algoritmekader recomenda verificações regulares de que um algoritmo funciona como pretendido, monitorização de alterações nos dados e avaliação do desempenho e dos resultados quando os dados mudam, e manutenção de um plano de monitorização contínua. Inclui também uma medida para um plano de emergência para parar o algoritmo. Estas recomendações colocam o tempo dentro do modelo de governação. Uma contratação que captura apenas a especificação inicial comprou uma fotografia de um serviço em movimento.

Nem todas as atualizações devem desencadear a mesma cerimónia. Uma correção de segurança que deixa o modelo, o limite de dados e o papel de decisão inalterados pode seguir um caminho diferente de uma nova família de modelos, de uma fonte de recuperação alterada ou de um novo limiar. O contrato pode definir materialidade em termos operacionais: uma alteração é material quando altera a tarefa, as pessoas afetadas, o caminho de prova, a consequência da decisão, a jurisdição de implantação, o subcontratante, a utilização de dados ou a capacidade de intervir. A definição exata exige juízo jurídico e técnico. O princípio é simples: a alteração faz parte da capacidade adquirida.

O acompanhamento deve preservar a informação necessária para tomar uma decisão. Um painel pode mostrar que um serviço está ocupado; pode não mostrar que uma fonte ficou desatualizada ou que os revisores estão a anular a mesma recomendação. A autoridade deve reter a versão relevante, o âmbito da tarefa, as condições das provas, a ação humana e o motivo de uma alteração. Deve saber quais as alterações que foram aceites, quais foram revertidas, quais foram restringidas e quais criaram uma nova questão de contratação.

Um fornecedor pode não conseguir dar aviso prévio de todas as alterações internas. O contrato pode ainda assim exigir uma notificação utilizável e um pacote de provas antes de o comportamento alterado ser utilizado como referência. A autoridade pode optar por uma implementação faseada, uma avaliação controlada ou uma suspensão temporária. A capacidade de pausar não é um castigo. É o que permite que um serviço público continue a ser responsabilizável enquanto os factos estão a ser apurados.

Um registo de alterações também protege contra uma falsa certeza. Se a autoridade não conseguir distinguir se uma diferença resultou de um novo modelo, de uma alteração de dados, de uma instrução, de uma solução manual ou de uma dependência externa, não deve afirmar que o sistema se comportou de forma consistente. A resposta correta pode ser restringir a utilização, recolher melhores provas ou interromper a via afetada. O dinheiro público não fica mais seguro porque a explicação é arrumada.

Interoperabilidade é a palavra educada para sair

As pessoas falam muitas vezes de interoperabilidade como se fosse uma cortesia técnica entre sistemas. Na contratação pública, é também um controlo de continuidade. Se um serviço público não conseguir mover os seus registos, configurações, provas, interfaces e conhecimento operacional para outra via, a autoridade pode estar legalmente livre para sair e praticamente incapaz de o fazer. O contrato criou uma dependência que o processo de contratação não nomeou.

O relatório do JRC da Comissão sobre a promoção da adoção da IA nas administrações públicas da UE descreve a contratação como um papel facilitador crucial e afirma que a interoperabilidade deve ser incorporada desde o início. Apresenta também a contratação estratégica como uma forma de reduzir a dependência de fornecedores não pertencentes à UE e de apoiar as startups europeias de IA, as soluções de código aberto e as GovTech. Este não é um argumento para comprar europeu por slogan nem para tratar o código aberto como uma garantia automática. É um argumento para fazer parte do valor adquirido a capacidade técnica e institucional de mudar de rumo.

A saída começa com uma lista do que deve sobreviver. Isso pode incluir registos de origem, identificadores, etiquetas, instruções, versões de modelos e configurações, conjuntos de avaliação, registos de auditoria, mapeamentos de utilizadores e funções, contratos de integração, estado de retenção, material de segurança e o significado dos campos. A lista depende do serviço. Um ficheiro portátil sem contexto pode ser menos útil do que um registo mais pequeno com a sua semântica e permissões intactas. A exportação é uma capacidade a testar, não uma caixa a assinalar.

Interoperabilidade significa também que a autoridade pode realizar uma comparação significativa. Consegue um destino processar os registos sem alterar silenciosamente o seu significado. Conseguem os revisores comparar um resultado antigo e um novo nas mesmas condições de tarefa. Consegue o serviço público continuar em modo reduzido se uma dependência não estiver disponível. Conseguem as provas permanecer legíveis depois de a interface desaparecer. Estas questões pertencem aos requisitos, à avaliação e ao contrato, porque uma saída descoberta durante uma emergência é geralmente uma escavação arqueológica.

Portabilidade não significa necessariamente que o fornecedor tenha de entregar todos os pormenores internos de implementação. Significa que a autoridade pode preservar a função pública e os registos pelos quais é responsável, sujeita a direitos legítimos e a restrições de segurança. O limite deve ser definido antes da assinatura. Se o modelo do fornecedor for inacessível, a autoridade pode ainda assim exigir dados de entrada e de saída portáteis, registos de decisão, avaliações, configuração e um caminho para reconstruir as obrigações públicas do serviço. Se não conseguir obter esse caminho, deve precificar a dependência de forma honesta ou recusá-la.

Um ensaio de saída é valioso porque transforma uma promessa contratual numa capacidade observada. Um comprador público pode testar uma exportação, inspecionar os campos, executar uma carga de trabalho representativa num destino controlado e comparar os registos resultantes. Pode registar o que não foi transferido e decidir se a lacuna é aceitável. O exercício não precisa de ser dramático. Um ensaio pequeno feito antes da renovação é melhor do que uma migração heroica realizada depois de o fornecedor se tornar a única pessoa que se lembra do sistema.

Sair é uma sequência de autoridade, exportação, significado, verificação, continuidade e encerramento. Um botão rotulado como exportação não é a sequência.

O custo é mais do que a linha no concurso

O preço é fácil de comparar quando o que está a ser comprado é estável. A aquisição de IA tem um horizonte de custo mais longo. Pode haver trabalho de integração, preparação de fontes, tempo de revisão, controlos de segurança, armazenamento, avaliação, atualizações de modelo, trabalho de acessibilidade, resposta a incidentes, suporte, exportação e substituição. Alguns custos são suportados pela autoridade. Outros são transferidos para os trabalhadores ou para o público quando um serviço se torna mais difícil de contestar. Uma aquisição que compara apenas a taxa inicial não é necessariamente económica. Está simplesmente a contar uma parte visível.

A Diretiva 2014/24/UE prevê a avaliação do custo do ciclo de vida quando a autoridade escolhe essa abordagem. A diretiva descreve custos como aquisição, utilização, manutenção, fim de vida e, quando relevantes e verificáveis, externalidades ambientais. Exige também que os documentos do concurso indiquem os dados que os concorrentes devem fornecer e o método utilizado para avaliar o custo do ciclo de vida. Esta é uma disciplina útil para a IA porque exige que o comprador diga o que será contabilizado, em vez de convidar cada fornecedor a trazer uma definição diferente de barato.

O mesmo princípio aplica-se à atenção humana. Se um sistema produz recomendações que precisam de revisão, o trabalho de as rever pertence ao modelo operacional. Se um serviço público precisa de um canal para correção, esse canal precisa de um responsável e de tempo. Se uma atualização de um fornecedor exige uma nova avaliação, a autoridade precisa de capacidade para a realizar. Estes não são argumentos contra a automatização. São lembretes de que a automatização muda o local onde o trabalho acontece. Uma poupança na fatura pode ser uma despesa na fila de espera se o processo de aquisição não nomear o novo trabalho.

O custo deve também incluir o custo de não poder sair. Uma dependência pode parecer barata enquanto é nova e tornar-se cara quando registos, conhecimentos especializados, integrações e expectativas públicas se acumulam à sua volta. O comprador pode pedir uma estimativa de migração, um inventário de dados e artefactos, uma obrigação de suporte e um calendário de ensaios. Pode comparar essas condições como parte do valor da oferta. A escolha não é entre otimismo e pessimismo. É entre uma dependência que é visível e uma que está escondida no tempo futuro.

O pensamento ao longo do ciclo de vida ajuda uma equipa de aquisições a dizer não sem fingir que a oferta visível mais barata é a opção neutra. A equipa pode rejeitar uma proposta porque as suas provas, o peso da revisão, o caminho de mudança ou o custo de saída não são compatíveis com o propósito público. Pode explicar a decisão com base em critérios publicados. Isso não é um gesto contra o mercado. É aquilo que um mercado com requisitos verificáveis deve permitir.

Os compradores públicos precisam de autoridade para dizer não

Uma equipa de aquisições não pode exercer um poder que a organização não lhe deu. Muitas autoridades têm pessoas capazes de avaliar questões legais, técnicas, financeiras e de serviço, mas a autoridade para combinar essas avaliações numa pausa ou recusa não é clara. O resultado é conhecido: as preocupações ficam registadas num documento, o entusiasmo noutro e a adjudicação avança porque ninguém sabe qual papel pode fechar o portão.

A autoridade deve nomear os papéis que podem aceitar, rejeitar, restringir ou pausar uma compra em cada fase. Esses papéis precisam de acesso às provas relevantes e de um meio para registar o motivo. Um responsável de aquisições pode ser dono do processo, um responsável de serviço do propósito público, um encarregado de proteção de dados de uma condição de privacidade, um responsável de segurança de um controlo, um revisor técnico de um teste e um papel sénior responsável da decisão final. A disposição exata varia. A ausência de disposição é a parte perigosa.

Uma condição de paragem útil não é um selo vermelho que diz risco elevado. É um facto que bloqueia a decisão seguinte. O propósito pretendido não está suficientemente definido. O fornecedor não consegue apresentar provas para um requisito material. A pessoa afetada não tem um canal de revisão utilizável. A autoridade não consegue inspecionar a alteração relevante. Os direitos sobre dados ou artefactos não são claros. O sistema não pode ser exportado ou substituído dentro do plano de continuidade. O revisor humano tem responsabilidade mas não tem autoridade. Cada condição pode ter um remédio diferente. Algumas exigem esclarecimento, outras uma alteração contratual, outras um âmbito mais restrito e outras um não.

As condições de paragem devem ser conhecidas antes de o concurso ser avaliado. Devem estar ligadas aos critérios de adjudicação e ao contrato, para que o comprador não esteja a inventar um novo padrão depois de ver a resposta do fornecedor. Devem também ser revisitadas após a adjudicação. Um requisito satisfeito no lançamento pode deixar de o estar após uma alteração material ou um novo uso. A capacidade de dizer não não é um único portão no fim. É uma autoridade mantida ao longo de toda a vida do serviço.

Considere uma equipa pública hipotética que adquire um serviço de encaminhamento de documentos. Os seus requisitos publicados incluem rastreabilidade da origem, um percurso de revisão humana, um aviso para alterações materiais do modelo, uma exportação de registos e um procedimento de cessação definido. Um proponente oferece uma demonstração forte, mas não permite que a autoridade inspecione a seleção da origem nem preserve as provas de encaminhamento versionadas. Outro proponente oferece menos funcionalidades, mas cumpre os requisitos de prova e de saída. A equipa não é obrigada a preferir a demonstração mais ruidosa. Pode aplicar os critérios declarados, fazer perguntas proporcionais e recusar a primeira oferta se um requisito material continuar por comprovar.

Essa decisão não deve ser redigida como um juízo moral sobre o fornecedor ou a tecnologia. Deve declarar o propósito público, o requisito, as provas recebidas, a condição não resolvida e a decisão permitida pelos documentos do concurso. Um não claro é mais respeitoso do que um talvez vago que mais tarde se torna uma renovação obrigatória. Também dá ao mercado um sinal útil: os compradores públicos pagarão por provas e controlo, não apenas por teatro de capacidades.

A autoridade humana para parar tem de ser utilizável num incidente. O operador deve saber a quem ligar, que estado do sistema preservar, que rota de serviço pode continuar e que comunicação é exigida. O registo da decisão deve distinguir a contenção imediata de uma decisão de aquisição mais longa. Um organismo público não precisa de esperar por uma investigação perfeita antes de evitar danos adicionais, mas deve evitar reivindicar mais certeza do que tem. A paragem é um controlo. A explicação pode desenvolver-se.

O aprovisionamento molda o mercado

O aprovisionamento público é uma das formas de a Europa decidir quais as capacidades que valem a pena construir. O relatório do JRC sobre o avanço da adoção da IA nas administrações públicas da UE descreve o setor público como uma força importante de moldagem do mercado. Liga a adoção bem-sucedida à governação, à preparação da força de trabalho, ao aprovisionamento responsável, à interoperabilidade e à confiança pública. Afirma também que o aprovisionamento estratégico pode reduzir a dependência de fornecedores não pertencentes à UE e apoiar startups europeias, soluções de código aberto e GovTech. A questão não é que uma autoridade pública se deva tornar num fundo de capital de risco. A questão é que os seus requisitos podem recompensar uma capacidade responsável ou recompensar um invólucro persuasivo em torno da dependência.

O Relatório Especial n.º 28/2023 do Tribunal de Contas Europeu tem o título Public procurement in the EU: less competition for contracts awarded for works, goods and services in the ten years up to 2021. O seu resumo público descreve a concorrência nos concursos públicos europeus como cada vez mais reduzida. Um mercado com menos concorrentes efetivos é um mau lugar para esconder requisitos vagos. Se a autoridade não puder comparar provas, pode escolher entre estilos de marketing em vez de escolher entre serviços. Dizer não a uma oferta não testável pode preservar as condições para uma melhor concorrência mais tarde.

Ao mesmo tempo, um comprador pode excluir acidentalmente fornecedores úteis ao exigir provas numa forma que apenas o maior fornecedor consegue produzir. Requisitos proporcionais, interfaces claras, formatos abertos e avaliações por fases podem permitir que organizações mais pequenas demonstrem uma capacidade limitada sem fingir ter os recursos de uma multinacional. O comprador deve ser rigoroso quanto ao propósito público e flexível quanto à implementação, desde que a implementação não afete esse propósito. É assim que um não se torna uma pergunta melhor em vez de uma porta fechada.

Moldar o mercado significa também recusar transformar a arquitetura privada de um fornecedor na definição da necessidade pública. Se um requisito nomear um modelo, uma cloud ou um fluxo de trabalho proprietário específico sem uma ligação justificada à tarefa, a concorrência pode ser reduzida antes de as provas serem vistas. Requisitos funcionais e resultados verificáveis dão aos compradores públicos mais margem para comparar abordagens. Tornam também o contrato menos frágil quando o componente escolhido muda.

Uma autoridade pública pode ser um cliente exigente sem se tornar um cliente difícil. Pode publicar as provas que espera, explicar o motivo de uma condição de paragem, oferecer um caminho para esclarecimentos e pagar por trabalho que crie capacidade pública duradoura. O mercado tem então algo útil a que responder. Não tem de adivinhar se o fator vencedor foi uma preferência oculta, uma demonstração bonita ou o preço de um problema futuro.

Um padrão de trabalho para um procedimento de aquisição que pode recusar

O padrão seguinte é uma recomendação prática, não um novo procedimento legal. É uma forma de manter a decisão pública visível enquanto um sistema passa da ideia à operação. Uma autoridade deve adaptá-lo à sua lei, setor, risco e método de aquisição. O importante é que cada etapa tenha um responsável, provas e um resultado permitido que inclua pausa ou recusa.

Primeiro, escreva o propósito público. Nomeie o serviço, as pessoas que o executam, as pessoas que o recebem, a decisão ou ação que pode mudar e a razão pela qual um sistema está a ser considerado. Indique o que está fora do âmbito. Se o propósito não puder ser descrito sem o vocabulário de produto do fornecedor, a autoridade ainda está em fase de descoberta de mercado. O resultado desta etapa é uma declaração do problema e uma decisão sobre se a aquisição é o próximo passo certo.

Segundo, escreva o limite das provas. Para cada afirmação material, indique o que mostraria que é verdadeira na tarefa pretendida. Nomeie as condições dos dados, o idioma, as necessidades de acessibilidade, os registos de origem, a versão, a base de referência e o caminho de revisão que tornam o teste significativo. Especifique o que deve ser inspecionável, o que pode ser mantido confidencial e o que deve ser entregue como registo contratual. O resultado desta etapa é um conjunto de requisitos que os concorrentes podem compreender e um plano de avaliação que pode alterar a adjudicação.

Terceiro, escreva o limite da autoridade. Nomeie as ações que o sistema pode sugerir, as ações que pode tomar, as ações que precisam de aprovação e as ações que são proibidas. Nomeie quem pode corrigir uma fonte, rejeitar um resultado, alterar uma regra, pausar um serviço e falar com uma pessoa afetada. Defina o que acontece quando o sistema está incerto ou as provas entram em conflito. O resultado desta etapa é um caminho humano mais específico do que uma caixa de verificação.

Quarto, escreva o limite da mudança. Identifique as mudanças que exigem aviso, avaliação, aprovação ou uma nova decisão de aquisição. Inclua modelo, dados, fornecedor, subcontratante, infraestrutura, local de processamento, interface, limiar, população, propósito e caminho humano. Decida quais provas ficam com o registo da mudança e quais podem ser ocultadas por razões legais. O resultado desta etapa é um registo mantido, em vez de uma promessa de que o sistema permanecerá estático.

Quinto, escreva o limite de saída. Liste os registos, dados, configuração, provas, permissões, integrações e conhecimento operacional que devem sobreviver. Defina formatos, prazos, suporte, verificação, serviço reduzido, transição, encerramento de acesso e eliminação. Ensaie uma exportação pequena antes de uma renovação ou de uma expansão material. O resultado desta etapa é um caminho que pode ser testado enquanto o fornecedor ainda é um parceiro, não apenas depois de a relação se ter tornado um litígio.

Sexto, escreva o registo público. Decida o que pode ser publicado sobre o propósito, o papel do sistema, as provas, o caminho humano, as mudanças, os incidentes e o contacto para contestação. Proteja informações confidenciais e pessoais sem transformar toda a decisão numa conversa privada. Um registo público pode dizer o que é conhecido, o que não é conhecido e quando ocorrerá a próxima revisão. A sua função não é fazer o sistema parecer perfeito. É tornar o julgamento da autoridade inspecionável.

Por fim, redija a recusa. A recusa não é um comunicado de imprensa dramático. É um resultado normal no registo da decisão: o requisito era material, as provas não o satisfizeram, o remédio foi considerado e a autoridade optou por recusar, restringir, suspender ou procurar uma via diferente. Um procedimento de contratação que não consiga produzir este registo fez com que a compra parecesse inevitável antes de ter merecido essa conclusão.

Estes portões podem estar representados numa resposta a um concurso, numa arquitetura inicial de projeto, num anexo contratual, numa reunião de revisão e num manual de incidentes. Não devem tornar-se num formulário maior por si só. Se um portão não alterar o que a equipa pode decidir, provavelmente é teatro documental. Se der a uma pessoa provas e autoridade para agir, faz parte do serviço.

Perguntas que vale a pena incluir num concurso

As melhores perguntas não são as que fazem um fornecedor repetir a sua linguagem de marketing. São as que tornam visíveis o propósito público e o limite das provas. O comprador pode adaptar as seguintes perguntas ao sistema e ao procedimento:

  • Que tarefa pública precisa o apoio proposto, e que tarefas estão fora da sua utilização prevista?
  • Que pessoas, registos e fontes de dados estão no âmbito, e quais devem ser excluídos?
  • Que resultado produz o sistema, e que decisão ou ação pode decorrer dele?
  • Que requisito pode ser demonstrado, qual pode ser inspecionado e qual será mantido contratualmente?
  • Como reproduzirá a autoridade um resultado com a versão, as fontes, a configuração e as condições da tarefa relevantes?
  • O que pode um revisor humano ver, alterar, rejeitar, escalar ou interromper antes de ocorrer uma ação consequente?
  • Que alterações ao modelo, aos dados, à infraestrutura, ao subcontratante ou às políticas exigem aviso prévio e reavaliação?
  • Que registos e artefactos pode a autoridade exportar, em que formatos, com que significado, direitos e estado de retenção?
  • O que acontece quando o serviço está indisponível, as provas estão incompletas ou uma pessoa contesta o resultado?
  • Que obrigações de apoio, auditoria, incidentes, formação e saída continuam após o primeiro lançamento?

Estas perguntas não substituem a diretiva de contratação, o Regulamento IA, a legislação de proteção de dados ou as regras setoriais. São pontos de partida para a autoridade tornar operacionais as suas próprias obrigações. Um fornecedor que consiga respondê-las claramente pode ainda assim não ser o fornecedor certo. Um fornecedor que não consiga respondê-las pode ainda assim ter um componente útil, mas a autoridade não deve confundir um componente útil com uma capacidade pública completa.

A nossa pequena nota

Na Dweve, o nosso AI Compas inclui um percurso de contratação e governação neutro em relação a fornecedores para organizações europeias reguladas. O material de RFI e RFP pede às equipas que classifiquem o caso de utilização, apliquem critérios de exclusão, comparem fornecedores, realizem uma prova de conceito e mantenham provas através da monitorização. Esse é o nosso contexto de implementação, não prova independente sobre contratação pública e não uma afirmação de que um único enquadramento serve todas as autoridades. Mencionamo-lo porque a disciplina aqui descrita é também a disciplina que tentamos usar no nosso próprio trabalho: definir o limite, exigir provas, manter a decisão humana e tornar visível a saída.

O nosso Trust Centre faz a mesma distinção num registo diferente. Um registo público pode descrever o que está documentado, o que está preparado e o que permanece um evento futuro sem transformar uma declaração de intenção em prova. Uma equipa de contratação merece a mesma honestidade dos seus fornecedores. O comprador deve poder ver o estado de uma afirmação, as provas por trás dela e o percurso para a contestar.

A lição

Uma autoridade pública não se torna responsável quando assina por um sistema de IA. Torna-se responsável quando o procedimento de aquisição consegue explicar por que razão o sistema pertence ao trabalho, que provas sustentam essa conclusão, quem pode intervir, o que acontece quando o sistema muda e como a função pública pode continuar se o fornecedor não puder.

As regras europeias de contratação pública já proporcionam hábitos importantes: os critérios devem estar ligados ao objeto do contrato, as informações devem ser verificáveis, os pesos devem ser indicados e as condições contratuais devem ser claras. As cláusulas de aquisição de IA da Comissão Europeia dão aos compradores públicos uma forma de discutir os sistemas de alto risco e os de risco não elevado e de atribuir responsabilidades. O Algoritmekader neerlandês transforma a contratação responsável em medidas práticas sobre finalidade, dados, provas, auditoria, controlo humano, suspensão e saída. O relatório do JRC insere a contratação pública no debate europeu sobre capacidades e soberania. O aviso do TCE sobre a redução da concorrência é um lembrete de que um concurso fraco não se repara com uma adjudicação confiante.

A palavra difícil continua a ser não. Não, a finalidade não está definida. Não, as provas não podem ser inspecionadas. Não, a via humana é decorativa. Não, o caminho da mudança é invisível. Não, o registo público não pode ser mantido. Não, o serviço não pode sair sem perder o trabalho que devia proteger. Cada não pode ser uma recusa, um estreitamento, uma pausa ou um pedido de melhor resposta. A autoridade deve decidir qual deles, registar o motivo e manter a decisão aberta a contestação.

Uma contratação que sabe dizer não não é uma contratação que receia a tecnologia. É uma contratação que sabe a diferença entre uma capacidade e uma promessa. Paga por um sistema que pode ser testado, supervisionado, alterado e abandonado. Dá aos fornecedores um concurso mais justo porque a questão é visível. Dá aos funcionários públicos uma via para intervir antes de um problema se tornar política. Dá às pessoas afetadas pelo serviço algo mais útil do que uma declaração de que um fornecedor foi aprovado.

Uma compra pública deve terminar com um serviço que a autoridade ainda possa governar. Se as provas forem sólidas, dizer sim tem significado. Se as provas forem fracas, dizer não é o trabalho público. O processo de aquisição deve ser capaz de conter ambas as frases.

Fontes