Uma estrada, um hospital e um modelo partilham um

Sistemas críticos de segurança falham de formas diferentes, mas exigem a mesma disciplina: uma alegação ligada a um contexto, evidência que possa ser...

Uma estrada, um hospital e um modelo partilham um problema: evidência.

The evidence has to survive the handover

A road designer, a hospital team and a model provider can all produce a convincing demonstration. The junction can look orderly on a plan. The clinical screen can look calm in a workshop. The model can return a sensible answer on a carefully selected set of examples. None of that settles the question that matters when the system enters ordinary life: what evidence supports this particular action, for these people, in these conditions, and who is entitled to change course when the evidence no longer holds?

That question is more useful than a debate about whether a road, a hospital or an AI system is “safe”. Safety is not a property that arrives in a cardboard box with the device. It is a continuing relationship between a purpose, a setting, a set of people, a system's limits and the work that happens when a limit is reached. A road needs to accommodate people who make mistakes and conditions that change. A clinical service needs to preserve judgement when information is incomplete, urgent or contested. An AI system needs to remain understandable enough that a person can see when its output has stopped being a useful contribution to a decision.

Europe already has parts of this discipline in different places. Road-infrastructure rules require procedures such as impact assessment, audits, safety inspections and network-wide assessment. The Artificial Intelligence Act asks high-risk systems to work with lifecycle risk management, technical documentation, logs, human oversight, appropriate accuracy, robustness and cybersecurity. European health institutions are discussing safety, equity, governance, workforce readiness and accountability together, rather than treating a clinical model as a piece of software that becomes harmless because its interface has a stethoscope on it.

The common thread is evidence. Not evidence as a thick folder assembled once, and not evidence as a scoreboard with a flattering average. Evidence as something attached to a claim, a context and a decision. A useful evidence record says what the system was meant to do, where the claim applies, which observations support it, which assumptions sit underneath it, what is still uncertain, who can intervene and which change means the argument must be reconsidered.

This is a less glamorous idea than autonomy. It is also more durable. It gives engineers a way to state their limits without pretending that a test set is a complete world. It gives managers a way to ask what they are actually accepting. It gives operators something better than a dashboard that lights up after the decision has already become difficult. Most importantly, it gives people affected by a system a route from an outcome back to the reasons and conditions that produced it.

Three domains, one awkward question

The road, the hospital and the model are not the same system. Their harms, legal duties, evidence bases and professional cultures differ. Nobody should copy a road audit into a clinical workflow, or paste a medical-device checklist onto a language model and call the job finished. The point is not to flatten the differences. The point is to notice a shared engineering problem: an automated or semi-automated system acts through a larger arrangement of people, procedures, interfaces, environments and assumptions.

Uma estrada é um lembrete especialmente claro porque não toma decisões no sentido humano. Ela molda-as. A geometria, as linhas de visão, a separação, os cruzamentos, as marcações, a gestão da velocidade, a manutenção e a rede envolvente influenciam o que as pessoas conseguem ver, do que conseguem recuperar e quão grave se torna um erro. As boas práticas de segurança rodoviária não dependem da fantasia de um utilizador da estrada permanentemente alerta e perfeitamente informado. Elas procuram tornar os erros previsíveis menos prováveis e menos punitivos. O quadro europeu para a gestão da segurança das infraestruturas rodoviárias reflete essa visão sistémica através de processos repetíveis de avaliação e inspeção, em vez de uma única declaração de que uma via foi aprovada.

Um hospital é diferente, mas também vive com o fosso entre uma descrição limpa e uma realidade em mudança. Um percurso clínico tem funções de pessoal, transições de cuidados, registos, equipamento, prioridades, interrupções e uma pessoa cujo estado pode não assemelhar-se ao caso médio que moldou um protocolo. Uma recomendação pode ser útil e ainda assim insuficiente. Um alerta pode ser tecnicamente correto e ainda assim chegar num momento em que não pode ser seguido com segurança. Um sistema pode melhorar uma parte de um fluxo de trabalho enquanto cria um novo encargo noutro lugar. É por isso que a discussão sobre a IA na saúde não pode parar no desempenho aparente de um modelo. Tem de incluir governação, responsabilidade clínica, qualidade dos dados, formação, confiança pública e os meios para identificar e corrigir danos.

Um modelo situa-se no mesmo tipo de arranjo. É treinado ou configurado num local, ligado a dados noutro, recebe um pedido ou uma tarefa de uma pessoa, é colocado atrás de uma interface, é observado por algumas pessoas e não por outras. Produz um resultado, mas esse resultado só se torna consequente quando alguém o trata como uma razão para agir. Entre o resultado e a ação encontram-se limiares, autoridade, pressão temporal, acesso ao material de origem, formação, incentivos e a possibilidade de discordância. Esses não são detalhes operacionais decorativos. Eles decidem se um componente tecnicamente competente permanece um componente seguro do sistema mais amplo.

Considere o seguinte como um composto explicitamente hipotético, não um relato de uma estrada, hospital, paciente, funcionário ou incidente reais. Uma autoridade local está a considerar um sistema que sinaliza locais para uma revisão de segurança rodoviária. Um hospital está a considerar uma ferramenta que ajuda a organizar documentos administrativos antes de o pessoal clínico os ver. Uma terceira organização está a considerar um modelo que redige um resumo de risco para um gestor de infraestruturas. Em cada contexto, uma demonstração inicial mostra que o sistema consegue encontrar padrões nos registos existentes. A demonstração ainda não responde se os registos representam as condições que o serviço verá no próximo mês, se um caso invulgar pode ser reconhecido, se as pessoas que recebem uma recomendação têm tempo e autoridade suficientes para a questionar, ou se a organização notará um padrão prejudicial antes de este se tornar trabalho normal. O problema das provas começa exatamente aí.

O erro fácil é pedir um único número. Qual é a precisão? Quanto tempo vai poupar? Quantos riscos vai detetar? Essas perguntas são legítimas, mas incompletas. Um número precisa de um denominador, uma amostra, uma definição, uma data, uma utilização pretendida e uma declaração do que foi excluído. Também precisa de uma relação com a decisão seguinte. Uma pontuação elevada numa tarefa estreita e estável pode sustentar uma afirmação estreita e estável. Não pode autorizar silenciosamente um fluxo de trabalho diferente, uma população diferente ou uma decisão com uma consequência diferente.

As provas não são um acessório decorativo

As provas tornam-se úteis quando conseguem mudar a opinião de alguém. Isto parece óbvio, mas muitos conjuntos de provas são construídos para parecerem completos, e não para tornar uma decisão questionável. Contêm capturas de ecrã, declarações de políticas, resumos de testes e assinaturas, mas não mostram que afirmação cada elemento apoia, que condição limita a afirmação, nem o que deve acontecer se a condição mudar. O resultado é papelada com um papel cerimonial. Pode provar que uma reunião ocorreu. Não consegue necessariamente dizer a um operador o que fazer às 07:40 quando o serviço está ocupado, os dados chegam tarde e uma recomendação não se ajusta ao caso que tem diante de si.

Um melhor ponto de partida é uma decisão nomeada. Não «implementar IA de forma responsável» nem «melhorar a segurança rodoviária», mas uma proposição com um limite. Por exemplo: este sistema pode priorizar uma classe definida de trabalho de revisão, num contexto operacional especificado, enquanto um papel nomeado permanece responsável por aceitar ou rejeitar a recomendação. Ou: este projeto pode ser aberto ao tráfego depois de os perigos identificados terem sido avaliados através do processo exigido e de os controlos identificados estarem em vigor. A formulação é deliberadamente menos entusiasmante do que um anúncio de produto. É um contrato com a realidade.

Uma vez nomeada a decisão, o resto do registo tem onde se ancorar. O propósito pretendido diz ao leitor o que não deve inferir. O contexto diz-lhe que local, fluxo de trabalho, utilizadores, dados, equipamento e processo envolvente importam. As provas registam testes, observações, material de origem, revisões e exercícios. Os pressupostos tornam as dependências visíveis: talvez um operador tenha formação, talvez um registo de origem esteja atualizado, talvez um alerta específico chegue a um papel específico a tempo. O proprietário identifica quem pode interpretar o material e intervir. Os gatilhos de revisão indicam que sinal, mudança ou falha de um pressuposto exige uma nova análise.

As provas tornam-se operacionais quando um leitor consegue ligar uma afirmação às suas condições, autoridade e via de revisão.

Esta estrutura tem uma consequência importante. Impede que as provas se afastem da utilização. Um teste não é apenas arquivado em «validação». Está ligado a uma afirmação sobre um comportamento específico em condições declaradas. Uma auditoria não é apenas a prova de que um auditor visitou. Torna-se um registo do que foi examinado, do que foi encontrado, do que permaneceu incerto e de que autoridade decidiu o que aconteceu a seguir. Uma avaliação de modelo não é um distintivo geral. É uma observação delimitada cuja relevância depende da versão do modelo, da tarefa, dos dados, da configuração e das condições de implementação.

The same record should make absence visible. If nobody has tested a system with an uncommon but consequential input, that is not a small embarrassment to hide beneath an average. It is an evidence boundary. If a human can technically override a recommendation but has no time, access or authority to do so in the real workflow, that is not meaningful oversight. It is a design gap. If a road safety inspection notices a recurring condition but no organisation owns the remedial work, the observation has not yet become a control. In serious systems, missing evidence is a result. It tells the organisation where it cannot yet make a claim.

Road safety offers a practical lesson in humility

Road safety has spent decades learning that harm is rarely explained by a single bad actor or a single bad component. The person driving too quickly, the crossing that is hard to read, the vehicle, weather, lighting, maintenance state, traffic mix and emergency response may all matter. That does not dissolve individual responsibility. It does prevent the shallow conclusion that every failure can be fixed by telling people to pay more attention. A system that only works when nobody makes a foreseeable mistake is not an impressively strict system. It is a fragile one.

The EU's road-infrastructure safety-management rules provide a useful counterweight to the idea that approval is a one-off event. They organise safety work around procedures that look at prospective consequences, design, operation and the existing network. The exact legal scope matters, and the rules should be read as road-infrastructure law rather than a general template for every technology. Still, their underlying habit is broadly valuable: inspect the system in the conditions in which it will operate, look for patterns rather than waiting for a dramatic event, and treat knowledge as a reason to adjust the arrangement.

That habit is not simply “collect more data”. Data without a question is a very efficient way of storing confusion. The road-safety question might concern where a crossing creates a conflict, which people are exposed to it, how often the conditions occur, what kind of mistake is foreseeable, which physical or operational measures reduce the risk, and how the organisation will know whether the measure has changed the situation. The evidence that matters is therefore mixed. It includes traffic conditions, design records, inspection observations, maintenance information, reports of harm and professional judgement. A map alone cannot carry the claim. Neither can a single collision statistic.

There is a useful human-factors point here. The system has to be designed for people as they are, not for a fictional user who reads every sign, judges every speed perfectly and never arrives distracted, tired, inexperienced, rushed, ill or simply surprised. That is not an excuse for careless behaviour. It is an acknowledgement that safety engineering has to work in the space between intention and actual human capability. When a system relies on a person to notice, understand and act, those three steps need evidence of their own. Can the signal be seen? Can its meaning be understood? Can the person act in time and with enough authority?

AI teams often miss this because the human is represented as a box at the end of a flow diagram. The box says “reviewer”, “operator” or “human in the loop” and therefore appears to solve the problem. But a role name does not describe an interaction. A useful review design needs to say what the person sees, what they do not see, what evidence they can inspect, whether they can request another route, when they are expected to disagree, what happens after disagreement and how the organisation learns from it. These questions are as ordinary as checking whether a crossing can be used safely in rain or darkness. They are also much more informative than a promise that a person remains involved.

Um hospital não pode fazer desaparecer a incerteza

Os cuidados de saúde tornam o problema das provas particularmente visível porque as consequências são pessoais e o contexto é complexo. Um sistema clínico ou administrativo útil pode ajudar os profissionais a encontrar informação, reduzir o trabalho repetitivo, detetar um possível padrão ou preparar material para revisão. Isso não o transforma numa autoridade clínica. A transição da informação para o tratamento, a priorização ou a recusa de cuidados acarreta obrigações que não podem ser delegadas numa interface. A pessoa responsável pelos cuidados precisa de saber o que o sistema fez, o que não fez e como reagir quando o resultado entra em conflito com os factos disponíveis no caso.

O trabalho da OMS/Europa sobre IA na saúde enquadra a questão no vocabulário que ela merece: segurança, eficácia, equidade, direitos humanos, transparência, responsabilização, governação e preparação da força de trabalho. A questão não é que todos os profissionais clínicos tenham de se tornar especialistas em aprendizagem automática. A questão é que um sistema não pode ser utilizado de forma responsável se as pessoas que dele se espera que dependam, supervisionem ou questionem não tiverem uma explicação utilizável dos seus limites. A formação faz parte do ambiente de controlo. O mesmo se aplica às vias de escalada, aos acordos de responsabilidade, às provas de desempenho no mundo real e a uma forma de doentes e profissionais levantarem preocupações sem primeiro se tornarem especialistas na tecnologia.

A Comissão Europeia coloca igualmente a IA na saúde num contexto regulamentar e operacional mais amplo. O seu material de saúde pública refere que o software de IA para fins médicos pode enquadrar-se nos requisitos de alto risco do Regulamento IA, incluindo a mitigação de riscos, a qualidade dos dados, a informação aos utilizadores e a supervisão humana. Não se trata de afirmar que todas as ferramentas utilizadas num hospital recebem a mesma classificação jurídica. É um lembrete de que a palavra «saúde» não atenua a necessidade de uma análise cuidadosa da finalidade prevista. Quanto mais consequente for a utilização, menos credível é confiar em garantias genéricas.

A prática clínica mostra também por que razão os limiares de intervenção devem ser explícitos. Um sistema pode ser autorizado a recuperar uma fonte, preparar um resumo, assinalar um campo em falta ou sugerir que um caso merece atenção. São atos diferentes. Cada um afasta-se um pouco mais da informação em direção à influência. Em determinado momento, um sistema pode ser autorizado a dar um passo operacional limitado, talvez com regras que restrinjam o âmbito e um registo que torne o passo reversível. Para além desse ponto, pode ser-lhe pedido que atue sem uma decisão humana contemporânea. As provas, a autoridade e a conceção de recuperação necessárias a esses níveis não são intercambiáveis.

Isto não torna a automatização impossível. Torna as afirmações proporcionais. Uma organização pode escolher uma tarefa modesta e bem delimitada e torná-la fiável antes de imaginar uma mais ampla. Pode manter o material de origem disponível em vez de transformar um resumo no único registo. Pode dar a um clínico ou a outro profissional responsável um meio real de pausar o sistema, e não um botão teórico escondido num manual de políticas. Pode monitorizar o que acontece após a implementação e tratar o comportamento inesperado como prova de que o argumento original precisa de ser revisto. Isso é mais lento do que declarar que o modelo assumiu o controlo. Em geral, é mais rápido do que tentar reconstruir uma decisão depois de a confiança já se ter perdido.

O modelo não é o sistema inteiro

The AI Act is valuable here because it refuses, in its high-risk provisions, to treat the model as the only relevant object. Article 9 sets out a documented, maintained and continuous iterative risk-management process. Article 10 concerns data and data governance. Article 11 and Annex IV address technical documentation. Article 12 addresses automatic recording of relevant events. Article 14 addresses effective human oversight, including the ability to understand relevant limits, override or reverse output where appropriate, and stop the system safely. Article 15 concerns accuracy, robustness and cybersecurity. These are not interchangeable paperwork categories. Together they point at a system that has to be understood across its lifecycle.

The law does not make a technical judgement for every organisation. It does not announce that a given performance measure is enough, nor does it make an operator competent by naming them in a document. It does something more demanding. It requires a way of connecting intended purpose, risk, documentation, records, human oversight and ongoing monitoring. That connection is precisely what gets lost when an AI project is described as a model acquisition rather than an operational change.

Take the commonplace claim that a human can override the model. Override what, exactly? A probability, a ranking, a generated paragraph, a routing decision, an automatic notification, a resource allocation or a physical action? Before or after it takes effect? With which information? Under which time constraint? Does the human see why the system reached the output, or merely that it did? Are there consequences for disagreeing? Is the disagreement recorded? Is it reviewed as a possible model, data or workflow problem? A truthful answer to these questions is more reassuring than a glossy assurance because it describes a control that can actually be exercised.

Human oversight is sometimes treated as a moral accessory: add a person to the process and the system becomes humane. It is better understood as an engineering relationship. The person needs a meaningful opportunity to detect a limitation, the authority to intervene, an action that changes the outcome, and a system state that remains safe when the intervention happens. A powerless reviewer is a witness. A reviewer who only sees an output after it has become irreversible is an auditor of a decision already made. Neither arrangement is equivalent to oversight.

Evidence should therefore grow as discretion and irreversibility grow. A retrieval tool that helps a professional find source material has one kind of evidence burden. A system that ranks work for attention has another, because ranking shapes what may be seen late or not at all. A constrained system that automatically performs an operational task needs clear boundaries, monitoring and a recovery route. A system that acts without a live decision needs the strictest case: a narrow purpose, evidence for the operating context, fail-safe behaviour, independent challenge where appropriate, clear ownership and continuing review. The designation is less important than the principle. More autonomy is a larger claim, not a marketing upgrade.

À medida que um sistema automatizado passa de informar uma pessoa para agir por si próprio, os requisitos de evidência, intervenção e recuperação têm de ser mais fortes, não mais fracos.

Os limiares impedem que uma ferramenta útil se torne uma decisão sem dono

Um limiar de intervenção é uma resposta prática a uma questão prática: quando é que o sistema pode fazer algo e quando é que tem de devolver o assunto? Deve ser visível antes da implementação, não descoberto através de uma reclamação. Um limiar pode depender da confiança, mas a confiança por si só não chega. Pode depender do tipo de decisão, das consequências de um erro, da qualidade e atualidade dos dados, da presença de evidências contraditórias, da disponibilidade de uma pessoa qualificada, da capacidade de recuperação e do grau em que o caso se insere no propósito declarado.

Os limiares não são prova de que um sistema é seguro. São uma forma de impedir que um sistema reivindique mais autoridade do que a sua evidência pode suportar. Um modelo pode ser capaz de resumir um registo, mas não de avaliar a sua completude. Pode identificar um termo, mas não determinar o seu significado jurídico. Pode produzir uma explicação plausível, mas não estabelecer a veracidade da explicação. Pode reconhecer um padrão rotineiro e ainda assim ser inadequado para casos invulgares, fontes contraditórias ou situações em que um pequeno erro seria difícil de reverter. O limiar é onde a organização transforma essas distinções em comportamento.

Para uma autoridade rodoviária, um limiar pode indicar que uma combinação de resultados de inspeção e indicadores de risco definidos conduz a uma revisão formal, enquanto uma combinação diferente exige uma medida temporária urgente. Os critérios exatos pertencem ao enquadramento jurídico e profissional relevante. A ideia transferível é que o percurso da observação à intervenção não deve depender inteiramente de quem está de serviço ou de qual preocupação é mais vividamente lembrada na reunião. A evidência não substitui o julgamento profissional. Dá ao julgamento um registo partilhado e um percurso repetível.

Para um hospital, um limiar pode distinguir entre uma ferramenta que prepara material para revisão e um sistema que pode executar uma ação administrativa limitada. Este último precisa de um registo claro do seu âmbito, uma forma de detetar uma exceção, um responsável nomeado para a exceção e uma forma de restaurar o estado anterior se a ação estiver errada. Se o sistema tocar numa decisão clinicamente material, o limiar precisa de ter em conta as obrigações clínicas, jurídicas e profissionais relevantes. A pessoa responsável não deve ser obrigada a reparar um resultado de automação opaco, sem rasto de origem e sem tempo para o inspecionar.

Para um sistema de IA em infraestruturas, um limiar pode distinguir uma previsão de uma ação de controlo. Uma previsão pode alertar um operador para uma condição que vale a pena verificar. Uma ação de controlo pode alterar um estado físico ou operacional. A segunda afirmação exige uma justificação muito mais sólida da qualidade dos dados de entrada, dos limites do sistema, das condições ambientais, da monitorização, da autoridade, da salvaguarda e da recuperação. Isto não é burocracia importada para frustrar engenheiros. É a descrição de engenharia do que acontece quando o custo de errar não é uma resposta dececionante numa janela de conversa.

O limiar mais útil é muitas vezes um limiar de recusa. O que deve levar o sistema a recusar agir? Que dado de entrada em falta, conflito, registo tardio, condição fora da distribuição, revisor indisponível ou alteração não testada deve desencadear uma pausa segura? As organizações tendem a descrever o que esperam que o seu sistema faça. Estão menos dispostas a escrever quando é que ele deve parar. No entanto, o comportamento de paragem de um sistema revela muitas vezes mais sobre a sua maturidade do que o seu comportamento de vitrina. A capacidade de dizer «este caso está fora da evidência» não é um defeito. É a prova de que o limite existe.

Os fatores humanos fazem parte da evidência, não são uma nota de rodapé

Os fatores humanos são por vezes reduzidos à observação de que as pessoas são falíveis. Isso é verdade, mas não é muito útil por si só. A questão de engenharia é como o trabalho está organizado em torno da atenção, memória, perceção, carga de trabalho, comunicação e autoridade humanas reais. Um aviso que não pode ser notado não é um aviso. Uma explicação complexa que não pode ser compreendida sob pressão de tempo não é transparência significativa. Um controlo de paragem que precisa da aprovação de alguém que está indisponível não é um controlo de paragem. Um ecrã de revisão que esconde o registo subjacente não é uma superfície de evidência.

O design de estradas torna isto concreto. As pessoas movem-se num ambiente físico com tempo limitado para ver, interpretar e agir. O sistema não pode ser avaliado apenas descrevendo os seus sinais pretendidos. Tem de ser avaliado considerando se as pessoas relevantes os podem usar no ambiente real. Os cuidados de saúde fazem o mesmo ponto num registo diferente. O leitor de um alerta ou recomendação pode ser interrompido, lidar com prioridades concorrentes, cobrir um colega ou confrontar-se com um caso que não se encaixa perfeitamente no processo. A IA acrescenta outra camada, porque uma saída fluente pode criar a falsa impressão de que o sistema ponderou evidência que apenas reafirmou.

A resposta não é exigir concentração sobre-humana. É desenhar e testar a transmissão. O que o sistema mostra primeiro? Qual é a fonte que a pessoa pode inspecionar? Como expressa a incerteza? Pode a pessoa pedir um caminho diferente? A interface distingue um registo confirmado de uma inferência? Conseguem saber se o modelo, a fonte de dados, a regra ou a configuração mudou? O que acontece ao feedback? Estas são questões empíricas e organizacionais. Merecem exercícios, observação, investigação com utilizadores e revisão pós-implementação, não apenas uma declaração de que a interface foi desenhada com o utilizador em mente.

Um registo de evidência responsável deve capturar a organização humana sem se tornar um dossiê sobre trabalhadores individuais. Pode registar função, autoridade, requisito de formação, intervenção esperada, tempo disponível, superfície de informação, via de escalada e resultado do exercício. Pode registar que um processo foi testado num cenário declarado sem fingir que o cenário prova todas as condições futuras. Pode preservar um rasto de decisão sem usar a monitorização como desculpa para vigilância desnecessária. Estes equilíbrios são difíceis. Ainda assim, são melhor tratados abertamente do que deixados a uma instrução vaga de que as pessoas devem «usar o seu discernimento».

O instinto neerlandês de tornar legíveis sistemas complicados tem aqui um lugar útil. Um cruzamento ciclável, um registo público ou um processo bem rotulado não se torna bom apenas por ser claro, mas a clareza permite que as pessoas vejam onde reside a responsabilidade. A boa governação tem uma modéstia semelhante. Não promete que não surgirá nenhum julgamento difícil. Torna visível o caminho para o julgamento difícil antes do dia em que é necessário. Não há cerimónia de inauguração para um caminho de escalada bem definido, o que talvez explique por que é tão frequentemente adiado.

A evidência tem prazo de validade

A parte mais difícil do trabalho baseado em evidências é aceitar que a evidência de ontem pode ser precisa e, ainda assim, deixar de ser suficiente. Um modelo muda. Uma fonte de dados muda. Um fornecedor altera um componente. Um fluxo de trabalho é reorganizado. Um novo grupo de pessoas utiliza o serviço. Uma estrada é alterada, mantida de forma diferente ou exposta a um padrão de tráfego distinto. Um hospital altera o pessoal, o software, os protocolos de triagem ou os registos. O teste original pode permanecer válido como observação histórica, mas a afirmação construída sobre ele pode precisar de um limite diferente.

É por isso que o histórico de versões não é um pormenor administrativo. Um leitor que não consiga identificar qual versão de um modelo, configuração, fonte de dados, política ou interface produziu um resultado não consegue reconstruir as condições da decisão. Uma equipa que não regista alterações materiais não consegue distinguir um problema novo de um antigo. Uma organização que trata o lançamento como o fim da garantia acabará por ter de redescobrir por que razão a sua confiança era justificada, precisamente no momento em que a resposta mais importa.

A monitorização pós-comercialização ao abrigo do Regulamento IA reconhece esta realidade do ciclo de vida para sistemas de alto risco. O requisito não é uma promessa de que a monitorização elimina a incerteza. É um reconhecimento de que a informação chega após a implementação e deve ter um caminho de regresso à gestão de riscos. A lição equivalente em segurança rodoviária é familiar: os sistemas devem ser inspecionados e avaliados enquanto operam, em vez de se assumir que permanecem seguros porque outrora cumpriram um requisito de conceção. Na saúde, a utilização no mundo real, a experiência da força de trabalho, o impacto nos doentes e os acordos de governação importam juntamente com qualquer avaliação pré-implementação.

Um gatilho de revisão deve ser específico o suficiente para ser utilizado. «Revisão periódica» é uma forma educada de pedir a futuros colegas que adivinhem. Um gatilho melhor nomeia o evento material: uma nova versão do modelo, uma alteração a uma fonte de entrada, um novo local de implementação, um grupo de utilizadores alterado, uma discrepância não resolvida, um padrão de reclamações, um sinal de segurança, uma incapacidade de executar uma etapa de supervisão ou uma mudança na autoridade que detém a decisão. A lista será diferente para cada sistema. O que importa é que o argumento original nomeie as condições que poderiam torná-lo obsoleto.

Isto também altera o significado de um registo de auditoria. Um registo de auditoria não deve ser um armazém cheio de eventos que ninguém consegue interpretar. Deve ser um caminho através do histórico do sistema. Qual afirmação estava em vigor? Qual evidência a sustentava na altura? Qual versão produziu o resultado? Qual pessoa ou função tomou a ação consequente? O que aconteceu quando o sistema foi contestado? Qual questão foi resolvida e qual permaneceu em aberto? O registo deve ser proporcionado. Deve também ser capaz de responder a uma pergunta real sem exigir uma expedição arqueológica heroica pelos registos de aplicação.

Como soa uma pergunta séria sobre evidências

Quando uma organização avalia um sistema crítico para a segurança, a pergunta útil raramente é «funciona?». Funciona para quem, com que objetivo, sob que condições, em comparação com quê e com que consequência se falhar? Essas perguntas podem parecer lentas porque impedem um sim fácil. São também as perguntas que tornam um sim posterior digno de valor.

Uma boa avaliação pede, portanto, uma cadeia e não uma coleção. Pede à equipa que nomeie o propósito pretendido e a decisão que se segue. Pede que identifique os danos e os modos de falha relevantes. Pede que diga que provas sustentam cada afirmação material e o que essas provas não mostram. Pede que indique que pressupostos têm de continuar a ser verdadeiros. Pede que defina quem tem autoridade para supervisionar, sobrepor-se, suspender e reparar. Pede que explique como o sistema se comporta quando faltam provas ou quando o caso está fora do âmbito. Pede que diga o que será monitorizado após a publicação e que mudança desencadeia uma nova avaliação.

Não existe uma pontuação universal que conclua este exercício. A estrada tem um contexto, o hospital outro, o modelo ainda outro. Um sistema pequeno e bem concebido pode ter um caso de provas mais sólido do que um sistema abrangente descrito com mais confiança. Uma afirmação estreita com um limite claro não é uma afirmação fraca. É o começo de uma afirmação honesta.

É também por isso que as nossas páginas de investigação descrevem perguntas explícitas, limites de provas e estado de acesso, em vez de apresentarem material de investigação como uma capacidade acabada por omissão. O método é modesto: identificar a pergunta, tornar visível o limite das provas e manter legível o estado de publicação. Não prova que um produto é adequado a uma implantação específica e não substitui a garantia específica do setor. É, ainda assim, um hábito útil. Se uma organização não consegue dizer o que as suas provas sustentam, o que não sustentam e quem as pode contestar, ainda não conquistou uma afirmação mais forte.

Uma estrada, um hospital e um modelo partilham um problema. Cada um precisa de uma forma de transformar conhecimento em ação sem esconder as condições em que essa ação é justificada. A resposta não é um ficheiro cerimonial, uma pontuação média ou um botão marcado como supervisão humana. É uma prática de provas que permanece ligada ao propósito, às pessoas, à autoridade e à mudança. Esse trabalho não é glamoroso. É assim que um sistema se torna responsável antes de ter de se tornar explicável.

Uma estrada, um hospital e um modelo partilham um problema: evidência.