Governança de IA tem um calendário de manutenção

A governança não é a aprovação que acontece antes de um sistema de IA entrar em funcionamento. É o trabalho quotidiano de observar, decidir, alterar,...

Governança de IA tem um calendário de manutenção

The calendar behind the policy

Most governance documents are written as though the interesting work happens before the system is used. Someone identifies a purpose. A team assesses a risk. A manager signs a line. A supplier supplies a PDF whose filename includes the word final, which is normally a small warning. Then the system enters ordinary life, where a data source is replaced, a person learns a workaround, a policy changes, a provider updates a component, or a previously unusual case becomes common. The approval remains in its folder. The world does not.

That is why AI governance needs a maintenance schedule. Not a ceremonial annual meeting with a slide showing seven green dots. A schedule of ordinary acts of care: checking whether the stated purpose is still true, reading signals that might change the risk judgement, deciding who may alter the system, rehearsing what happens when it must be stopped, recording why a change was made, and retiring evidence when its conditions have expired. This is less glamorous than a launch announcement. It is also where accountability either becomes real or quietly evaporates.

The distinction matters because AI systems do not stay where their initial assessment put them. A model may be unchanged while its inputs, users, interface, deployment route, connected tools, business process or legal context changes. A model may change while the use appears stable. A system may remain technically available but become operationally unsuitable because the people who could challenge it have moved jobs, because the review queue has filled, because a new downstream use has given its output a different consequence. Governance that treats the release date as the finish line is governing a photograph.

European rules already contain a more demanding idea. For high-risk AI systems, Article 9 of the AI Act calls risk management a continuous iterative process, planned and run through the whole lifecycle, with regular systematic review and updating. Article 72 requires a proportionate, documented post-market monitoring system that actively and systematically collects, documents and analyses relevant performance information throughout a system's lifetime. The point is not that every small piece of software needs the same apparatus. It is that consequential technology needs an operating rhythm, not merely a starting file.

The useful question is therefore not, “Do we have an AI governance framework?” It is, “What happens next Tuesday when the evidence no longer fits the service?” Who sees that first. What information do they have. Who can decide whether it is an ordinary correction, a material change, an incident or a reason to pause. How is the original decision preserved without turning it into an excuse. And when the system is still working technically, but the institution has stopped understanding the conditions of its use, who is allowed to say that working is no longer good enough?

A maintenance schedule does not answer those questions with a generic dashboard. It assigns them to people and moments. It gives each record a reason to be revisited. It makes a system's continued use conditional on a living relationship between evidence, authority and the real work around it.

What decays after launch

Software does not have to fail to become less governable. The most common decay is quieter. A team has a good description of intended use, but the service grows sideways. An assistant made for internal drafting is copied into a customer route. A classifier built to sort a fixed set of documents receives a new kind of submission. A system originally reviewed by a small group becomes part of a wider process where nobody knows the limit that mattered at the start. Nothing in that account requires an invented disaster. It is simply what happens when an institution changes faster than its records.

O propósito degrada-se primeiro porque muitas vezes é escrito como um substantivo, quando na realidade é um limite. O «apoio à decisão» não é um propósito adequado se o registo não puder indicar qual a decisão, para quem, com que dados de entrada, com que autoridade, e o que a saída está proibida de desencadear. Uma declaração de propósito deve ser revista quando uma nova equipa começa a utilizar o sistema, quando uma saída começa a abrir ou fechar um caminho com consequências, quando uma nova população é afetada, ou quando a transmissão humana se torna menos significativa. As palavras podem permanecer as mesmas enquanto a consequência prática cresce consideravelmente.

A evidência degrada-se a seguir. Um resultado de avaliação é uma observação em condições declaradas. Pode ser útil durante muito tempo, mas não é imortal. O estado medido do modelo pode ter mudado. A distribuição dos dados pode ter-se alterado. As pessoas que utilizam o sistema podem agora interpretar a sua saída de forma diferente. Uma referência pode abranger um subconjunto que era inicialmente representativo e que deixou de o ser. O próprio teste pode continuar a ser reproduzível enquanto o argumento para nele confiar se tornou fraco. Manter o relatório é uma boa prática de arquivo. Tratá-lo como evidência atual sem verificar as suas condições é outra coisa.

As interfaces também se degradam. Isto é muitas vezes ignorado porque uma alteração na interface pode parecer inofensiva. Uma nova predefinição, um botão mais proeminente, uma explicação encurtada, uma chamada de ferramenta adicionada ou um caminho de escalada alterado podem mudar o que os utilizadores realmente fazem. O modelo é o mesmo, por isso a equipa afirma que não ocorreu nenhuma alteração no modelo. Isso pode ser tecnicamente exato e operacionalmente irrelevante. Se a interface fizer uma recomendação parecer obrigatória, se remover o contexto necessário para contestar um resultado, ou se permitir que uma saída viaje mais longe do que antes, a questão de governação mudou mesmo que os pesos não tenham mudado.

A autoridade degrada-se quando a responsabilidade existe no papel mas já não na prática. Um proprietário nomeado pode ter saído. Uma função de revisão pode permanecer num organograma enquanto a pessoa que a ocupa não tem nem tempo nem informação para exercer juízo. Uma autoridade de paragem pode ser atribuída a um grupo sénior que não sabe que lhe foi atribuída. Um contrato com um fornecedor pode apontar para um contacto de escalada que pode receber uma notificação mas não pode fazer uma alteração. A governação tornou-se então uma velha lista telefónica com tipografia ligeiramente mais confiante.

As dependências degradam-se por acumulação. Um serviço pode adicionar uma fonte de recuperação, um fornecedor de identidade, um produto de monitorização, uma rota de inferência, uma fila, uma camada de armazenamento, ou outro modelo. Cada adição pode ser sensata. Em conjunto, alteram o sistema que está realmente em funcionamento. A DORA faz este ponto num contexto financeiro ao exigir que as entidades identifiquem, classifiquem e documentem funções de negócio apoiadas por TIC, ativos, funções, responsabilidades e dependências, e que revejam a documentação relevante pelo menos anualmente e quando ocorrer uma alteração importante. Não é uma regra de IA. É um lembrete útil de que o objeto que necessita de manutenção é o sistema no seu ambiente de trabalho, não o componente com o nome mais na moda.

Por fim, a memória degrada-se. Uma organização pode reter milhares de linhas de registo e ainda assim perder a razão de uma decisão. Os registos podem dizer que um evento ocorreu. Não dizem automaticamente por que razão foi definido um limiar, quem aceitou uma limitação, quais os casos excluídos de um ensaio, ou o que uma equipa pretendia verificar após um lançamento. Essa informação tende a sair com as pessoas, a menos que seja transformada num registo com um proprietário e um ponto de revisão. Uma trilha de auditoria que não consegue explicar o juízo em torno do evento é útil, mas incompleta.

Nada disto é um argumento a favor de suspeição permanente ou de uma reunião de comissão sempre que um menu muda. A proporcionalidade importa. O próprio Regulamento IA descreve a monitorização pós-comercialização como proporcional à natureza da tecnologia e ao risco do sistema de alto risco. O objetivo da manutenção não é tornar impossível a melhoria comum. É tornar a organização boa a notar quais as melhorias que não são comuns.

A lei já pensa em ciclos

As regras tecnológicas europeias são frequentemente descritas como obrigações de conformidade, como se o trabalho fosse uma única submissão seguida de um carimbo. Lidas com mais atenção, a sua lógica operacional é cíclica. Pedem às organizações que identifiquem, monitorem, documentem, reportem, revejam, testem e melhorem. O vocabulário difere consoante o setor porque os riscos diferem. O instinto de manutenção é notavelmente consistente.

Para os sistemas de IA de alto risco, o Regulamento IA coloca o pensamento de ciclo de vida perto do início dos requisitos. O artigo 9.º exige que um sistema de gestão de riscos seja estabelecido, implementado, documentado e mantido. Descreve esse sistema como contínuo e iterativo, planeado e executado ao longo de todo o ciclo de vida, com revisão e atualização sistemáticas e regulares. O sistema deve identificar e analisar riscos conhecidos e razoavelmente previsíveis, incluindo riscos associados à utilização prevista e à utilização indevida razoavelmente previsível. Deve também utilizar as informações recolhidas através da monitorização pós-comercialização. Isto é uma instrução para tornar a avaliação inicial revista. Não permite que a avaliação inicial se torne uma peça de museu.

O artigo 72.º é mais específico sobre o que acontece depois de colocar um sistema de alto risco em serviço. Os fornecedores devem estabelecer e documentar um sistema de monitorização proporcional à tecnologia e ao risco. Este deve recolher, documentar e analisar ativa e sistematicamente dados relevantes sobre o desempenho ao longo da vida útil do sistema, para que a conformidade contínua com os requisitos relevantes possa ser avaliada. Quando relevante, inclui a análise da interação com outros sistemas de IA. Isto é importante para implementações reais porque o comportamento significativo de um sistema pode surgir na fronteira: um resultado entra noutra ferramenta, um motor de políticas transforma uma pontuação numa ação, um humano vê uma interface que altera o peso de uma recomendação, ou um fluxo de trabalho a jusante cria uma nova consequência.

O Regulamento não pede que a monitorização se torne vigilância passiva de todos os que utilizam um serviço. Pede informações relevantes, e o ambiente jurídico envolvente continua a aplicar-se. Um design de manutenção deve, portanto, começar com um propósito para cada sinal. Que pergunta o sinal responde. A informação agregada é suficiente. A revisão precisa de conteúdo, identidade ou apenas de um facto operacional com versão. Quem pode aceder-lhe. Durante quanto tempo é retida. Como pode ser contestada. Recolher mais porque um painel aceita mais campos não é uma estratégia de manutenção. É armazenamento com ambições.

O mesmo capítulo junta a monitorização ao tratamento de incidentes graves. O artigo 73.º exige que os fornecedores de sistemas de alto risco colocados no mercado da União comuniquem incidentes graves às autoridades de fiscalização do mercado relevantes depois de estabelecida uma relação de causalidade, ou uma probabilidade razoável da mesma. Estabelece prazos que variam com a gravidade, incluindo dois dias para uma infração generalizada ou um incidente grave do tipo especificado. Exige investigação, avaliação de riscos e ação corretiva após a comunicação. A perceção operacional importante não é o número de dias. É que a resposta a incidentes não é um processo separado de relações públicas. Faz parte do ciclo de evidências que deve alterar a gestão de riscos, a documentação e a operação futura.

O NIS2 torna a questão da propriedade clara na cibersegurança. O seu artigo 20.º estabelece que os órgãos de gestão das entidades essenciais e importantes aprovam as medidas de gestão do risco de cibersegurança, supervisionam a sua implementação e podem ser responsabilizados por infrações. O artigo 21.º exige, por sua vez, medidas técnicas, operacionais e organizativas adequadas e proporcionadas, incluindo o tratamento de incidentes, a continuidade do negócio, a segurança da cadeia de abastecimento e a segurança na aquisição, no desenvolvimento e na manutenção. Isto é útil muito para além das entidades a que o NIS2 se aplica. A governação não é uma instrução enviada de cima para baixo a partir de um dossiê do conselho. Se as pessoas com autoridade formal não revirem as medidas nem compreenderem as consequências das suas escolhas, a organização criou um título sem controlo.

O NIS2 trata também a comunicação de incidentes como uma obrigação de serviço. Os incidentes significativos devem ser notificados sem demora indevida e, quando adequado, os destinatários dos serviços devem ser informados quando for provável que um incidente significativo afete negativamente a prestação do serviço. Um incidente é significativo não só quando perturba a própria organização, mas também quando afeta outras pessoas com danos materiais ou não materiais consideráveis. Esse limite é útil para a governação da IA. Uma equipa não deve olhar apenas para se o gráfico de disponibilidade do sistema continua verde. Um sistema pode estar disponível e ainda assim criar um problema operacional ou relacionado com direitos importante.

O DORA fornece outro padrão prático. As entidades financeiras devem identificar e documentar as funções de negócio apoiadas por TIC, funções, responsabilidades, informações e ativos de TIC, bem como as suas dependências. Revem a adequação das classificações e da documentação conforme necessário e pelo menos anualmente, e realizam uma avaliação de risco em cada alteração importante na infraestrutura, nos processos ou nos procedimentos que afetem funções ou ativos apoiados. Mais uma vez, isto não é um argumento de que todas as organizações são entidades financeiras. É um exemplo de uma regra madura que trata o inventário, a alteração e a revisão como trabalho interligado. Um sistema vivo precisa de um mapa, e um mapa precisa de uma data.

A linguagem do DORA sobre a gestão de alterações é particularmente sóbria. Exige políticas, procedimentos e controlos documentados para alterações em software, hardware, firmware, sistemas e parâmetros de segurança. As alterações devem ser registadas, testadas, avaliadas, aprovadas, implementadas e verificadas de forma controlada. Essa sequência não é uma afirmação de que um modelo de IA pode ser sempre testado até à segurança. É uma forma de recusar a ideia de que uma atualização de produção se justifica a si mesma. Uma alteração deve ter uma razão, uma avaliação, um percurso de aprovação, um registo de implementação e uma verificação do resultado.

A ISO/IEC 42001 não é legislação e uma página pública de produto não substitui a própria norma. Ainda assim, a ISO descreve a norma como um sistema de gestão de IA baseado em Planear-Fazer-Verificar-Agir, destinado a ajudar uma organização a gerir os riscos e oportunidades relacionados com a IA em toda a organização, em vez de apenas examinar aplicações individuais. O ciclo é a ideia útil. Planear estabelece uma intenção limitada. Fazer coloca-a em funcionamento. Verificar pergunta se as evidências apoiam a confiança continuada. Agir altera o sistema de trabalho. Repetir esse ciclo não é burocracia por si só. É o reconhecimento mínimo de que os sistemas e as instituições não ficam parados.

Um ciclo de governação tem de devolver evidências a uma decisão. Caso contrário, é apenas um registo de coisas que foram notadas.

A monitorização tem de poder importar

Monitorização é muitas vezes discutida como uma atividade técnica, o que é compreensível. Os sistemas produzem telemetria. As equipas escolhem métricas. Os painéis mostram linhas que sobem, descem e, ocasionalmente, inspiram reuniões alarmantes. Mas a parte difícil não é recolher um sinal. A parte difícil é concordar sobre o que o sinal pode mudar.

Um plano de monitorização começa com uma questão de decisão. Uma reclamação pode indicar que uma explicação não é clara, que uma entrada está errada, que um utilizador encontrou uma limitação, ou que a organização desenhou mal um percurso de recurso. Um aumento nas anulações humanas pode indicar um declínio no ajuste do modelo, uma melhoria na confiança da equipa, uma alteração de política, dados de origem desatualizados, uma nova classe de casos, ou uma interface que está a induzir os revisores em erro. Um aumento nas recusas pode indicar que um controlo de segurança está a funcionar, que uma dependência se tornou pouco fiável, ou que um produto está a ser utilizado fora do seu propósito declarado. A contagem bruta não é a conclusão. É um convite para investigar uma relação.

É por isso que um plano útil separa a observação da interpretação. A observação diz o que foi registado, com que versão, percurso, tempo, contexto e confiança. A interpretação diz o que a organização pensa que o sinal pode significar e que explicações alternativas permanecem. A decisão diz quem pode escolher uma resposta. O registo diz o que mudou e porquê. Isto é mais lento do que tratar cada alerta como evidência de falha do modelo. É mais rápido do que enviar um problema mal compreendido para um ciclo de retreino e descobrir que a falha real era política, qualidade da origem, direitos de acesso ou pessoal.

As métricas também devem corresponder à consequência do sistema. Uma pontuação de qualidade do modelo pode ser relevante, mas raramente será suficiente. Se um resultado afeta uma fila, uma equipa pode precisar de saber atrasos, exceções não tratadas, reversões e quais os casos que estão a ser enviados para revisão manual. Se um assistente recomenda fontes, uma equipa pode precisar de saber a disponibilidade das fontes, correções de citações, respostas contestadas e se os utilizadores agem com base em material fora do âmbito declarado. Se um sistema filtra conteúdo, a revisão pode precisar de padrões de reclamação, resultados de recursos, cobertura linguística e razões para anulações. A monitorização deve viajar ao longo do caminho onde o sistema tem efeitos, não parar no ponto onde o modelo produziu um token ou uma pontuação.

O percurso até a um humano também precisa de monitorização. É fácil escrever “supervisão humana” numa política e difícil mostrar se a pessoa pode realmente exercê-la. Com que frequência as pessoas anulam. Têm acesso às entradas e razões necessárias para o fazer. Uma anulação chega ao processo que produziu o resultado, ou apenas acrescenta uma nota no final. Quanto tempo demora uma escalada. Certos casos nunca chegam ao percurso de revisão porque a interface esconde a possibilidade. Estas são questões operacionais. São também questões de governação porque a resposta determina se a supervisão humana é real ou decorativa.

Nem todos os sinais precisam de ser públicos. Alguns serão comercialmente sensíveis. Alguns dirão respeito à segurança. Alguns podem conter dados pessoais e não deveriam ter sido recolhidos em primeiro lugar. A disciplina de manutenção é tornar esses limites explícitos. Uma revisão pode precisar de padrões agregados em vez de um arquivo completo de conteúdo. Pode precisar de um estado capturado em vez de um registo de cada interação. Pode precisar de acesso protegido para um investigador de incidentes e uma explicação pública separada do método. Transparência não significa publicar material operacional bruto. Significa tornar inteligível a existência, o propósito, o limite e a propriedade de um controlo.

Há uma diferença pequena mas importante entre um plano de monitorização e uma lista de desejos. Um plano diz quais os sinais recolhidos, como são protegidos, o que desencadeia a revisão, quem é responsável pela revisão, quais são os resultados possíveis e como a decisão entra no registo de alterações. Uma lista de desejos diz que a organização vai monitorizar a qualidade, a segurança, a equidade e a satisfação dos utilizadores. A primeira pode ser testada. A segunda encaixa muito bem numa apresentação de estratégia e em mais lado nenhum.

Uma boa monitorização também torna visíveis os não-acontecimentos. Se não chegam relatórios, é porque o sistema não causou qualquer problema, porque o canal de comunicação é inacessível, porque as pessoas não sabem que existe, ou porque o processo não preserva os relatórios? Se um limiar de incidente não é ultrapassado, é porque o sistema está estável ou porque o limiar não tem relação com o dano real? A ausência de um sinal pode ser uma prova, mas apenas depois de o percurso de recolha ter sido examinado. O silêncio não é automaticamente uma garantia. Às vezes é apenas um formulário com má sinalização.

A resposta a incidentes é uma forma de memória institucional

Um processo de incidentes deve começar antes do incidente, porque os primeiros minutos de um acontecimento invulgar são uma má altura para inventar autoridade. O processo precisa de uma forma de receber uma preocupação, preservar provas suficientes para a compreender, proteger as pessoas de exposição contínua, decidir se o acontecimento cumpre um limiar definido e comunicar com as pessoas que precisam de agir. Também precisa de um caminho de regresso ao sistema de governação. Sem esse caminho final, a organização lida com o episódio e depois recria as suas condições prévias com uma eficiência admirável.

A DORA expressa isto claramente para incidentes relacionados com as TIC. Exige que as entidades financeiras definam, estabeleçam e implementem um processo de gestão de incidentes para detetar, gerir e notificar incidentes. Registam incidentes e ameaças cibernéticas significativas e mantêm procedimentos para uma monitorização, tratamento e acompanhamento consistentes e integrados, de modo a que as causas profundas sejam identificadas, documentadas e tratadas. O processo deve estabelecer indicadores de alerta precoce, atribuir funções e responsabilidades para diferentes cenários e definir acordos de comunicação e escalonamento. Estes são requisitos específicos do setor financeiro. A sua lógica básica é amplamente útil: um incidente deve deixar a organização com melhor conhecimento do que aquele que tinha antes.

Para a IA, a questão das provas merece cuidado adicional. Uma equipa pode querer alterar um modelo ou serviço imediatamente após tomar conhecimento de um resultado prejudicial. Por vezes, a contenção urgente é exatamente o correto. Mas uma alteração não controlada também pode destruir a capacidade de compreender o que aconteceu. O Regulamento IA diz que um fornecedor que investigue um incidente grave não deve alterar o sistema de IA de uma forma que possa afetar a avaliação posterior das causas antes de informar as autoridades competentes dessa ação. Isto não cria uma licença para deixar as pessoas expostas enquanto se preserva uma experiência imaculada. Torna o compromisso visível. Contenha o risco, preserve o estado relevante, registe a intervenção e evite transformar a investigação numa reconstrução feita de memória.

Um registo de incidente útil tem várias camadas. Há a observação comunicada, que pode estar incompleta ou ser contestada. Há o contexto técnico e operacional, incluindo a versão, o percurso, o estado e os sistemas ligados que são relevantes. Há a avaliação do impacto e da incerteza. Há os passos de contenção, incluindo quem os tomou e o que alteraram. Há a investigação, que deve distinguir provas de hipóteses. Depois, há a decisão sobre a ação corretiva e o acompanhamento que verifica se funcionou. Fundir todas estas camadas faz um relatório inicial parecer uma conclusão final, ou uma conclusão posterior parecer tão certa como o primeiro alerta.

Communication is part of maintenance, not a decorative epilogue. People affected by an interruption or a significant threat may need a practical remedy. Operators need to know whether to stop, continue with limits or use a fallback. Leadership needs a clear account of impact, uncertainty and decision rights. A regulator may need a defined report. Suppliers may need to investigate an interface or dependency. The messages do not need to be identical, but they must share the same factual core. An organisation that gives its teams incompatible accounts is not being careful. It is manufacturing the next incident.

There is no need to invent a dramatic outage to understand this. Consider a clearly labelled hypothetical: a review team sees a cluster of unexpected corrections after a new source format enters an otherwise familiar workflow. The first question is not whether the model has “gone rogue”, a phrase best left in the bin with several other phrases. The question is what changed. Is the source format altering the input. Is the retrieval route exposing unsuitable material. Has a policy condition moved. Is the interface making reviewers miss context. Are affected cases being corrected quickly enough. The response may be to pause one route, revert a configuration, add validation, revise guidance, or find that the source should never have been admitted. The point of the hypothetical is not the plot. It is that a prepared process prevents the organisation from guessing its way through the first hour.

After an incident, the maintenance schedule should ask more than whether the visible fault is fixed. Did the detection signal work. Did the right person receive it. Did they have authority. Did the log preserve the relevant context. Was the escalation route usable. Did the public or customer-facing message match what was known. Did a decision create a new monitoring requirement. Did a training or documentation gap make the event worse. The answers turn an incident from an isolated interruption into a change in the operating model.

Change needs a second clock

Every system has a technical clock. Versions are built, deployed, rolled back and replaced. Governance needs a second clock: the timetable for reconsidering whether the evidence, purpose and authority are still adequate. These clocks sometimes move together, and sometimes they do not. Treating them as the same is a reliable way to miss important changes.

A technical change can be small and still matter. A new retrieval collection might alter the sources used in answers. A changed prompt or policy rule might alter the set of cases a system refuses. A configuration update might change where data travels. A new version of a dependency might change latency, logging or available safety controls. The proper response depends on the system and its consequence. The maintenance schedule should not declare every change material in advance. It should provide a way to decide what needs testing, re-approval, public notice, a risk reassessment, a new captured state or simply a record.

Conversely, a governance change can occur with no code deployment at all. A service may be used by a new department. A procurement contract may add a processor. A legal interpretation may change the conditions of a workflow. A route may move from internal experimentation to external access. An existing output may begin to influence a decision further downstream. The technical team may see no release. The people affected may see a very different system. A maintenance schedule has to notice both clocks.

O DORA utiliza uma regra de classificação prática: realizar uma avaliação de risco em cada alteração importante na infraestrutura de redes e sistemas de informação, processos ou procedimentos que afetem funções ou ativos suportados. Exige também que os inventários sejam atualizados periodicamente e sempre que ocorra uma alteração importante. No trabalho com IA, a expressão “alteração importante” não deve ser tratada como algo evidente por si só. As equipas devem definir os seus critérios antecipadamente. Inclui uma alteração de finalidade pretendida, uma nova fonte de dados, um novo estado de modelo, uma nova permissão de ferramenta, uma nova população, uma rota de override humano alterada, uma explicação modificada ou uma nova dependência externa? A resposta variará. A ausência de resposta é, em si mesma, um risco.

Um registo de alteração não é um changelog escrito para aplauso público. É um argumento que liga um estado anterior, uma razão, uma avaliação, uma decisão, uma implementação e uma verificação. Para algumas alterações, a versão pública pode ser breve: uma política relevante ou um limite visível ao utilizador foi alterado, com efeitos a partir de uma data indicada, com uma ligação para o que é diferente. Para evidência interna, o registo pode incluir mais detalhes sobre avaliação, controlos de acesso, contexto de incidente ou informações do fornecedor. O importante é que ambas as camadas apontem para a mesma decisão, em vez de se tornarem histórias separadas.

A identidade de versão é especialmente importante quando um sistema se adapta ao longo do tempo. Um nome de produto estável nem sempre consegue identificar o estado que produziu um determinado resultado. Mas tentar atribuir um número de versão permanente a cada estado transitório pode criar um tipo diferente de ficção. Uma abordagem melhor é distinguir a identidade duradoura do modelo ou serviço do estado capturado, da configuração e da evidência necessárias para uma revisão ou reprodução definida. O registo indica então o que foi inspecionado, sem fingir que tudo ficou congelado para sempre.

A verificação de alterações é onde muitos registos se tornam otimistas. Uma organização aprovou uma correção, por isso o incidente está encerrado. Mas a implementação não é verificação. O novo controlo funcionou em condições realistas? Criou um problema diferente? O fallback funcionou? Os revisores humanos receberam as orientações alteradas? A métrica relevante moveu-se na direção pretendida? A explicação ainda corresponde ao serviço? A verificação pode mostrar que uma alteração deve ser revertida, refinada ou mantida com uma nova limitação. É permitido que seja inconveniente. Isso faz parte do seu trabalho.

Um calendário dá a este trabalho um ritmo comum. Alguns registos são revistos após um gatilho. Outros precisam de uma data fixa, porque esperar por um gatilho pressupõe que a organização reconhecerá sempre o gatilho. Uma declaração de finalidade pode precisar de revisão quando o uso muda e num intervalo planeado. Uma avaliação pode expirar após uma versão, rota de dados ou contexto mudar. Um plano de incidente pode precisar de uma data de ensaio, porque um plano que nunca foi usado pode estar perfeitamente escrito e praticamente imaginário. Uma rota de saída pode precisar de ser testada antes de ser urgentemente necessária. A data não garante cuidado. Torna a negligência mais fácil de ver.

Os registos podem permanecer num arquivo enquanto perdem a autoridade para suportar uma decisão atual. A data de revisão torna essa distinção visível.

Expirar não é falhar

As equipas resistem muitas vezes a datas de expiração porque expirar soa a acusação. Não é. É uma afirmação sobre o âmbito. Um resultado de calibração pode ser válido para o estado do modelo e as condições de entrada que foram testadas. Uma avaliação de proteção de dados pode ser cuidadosa para o percurso de tratamento que descreve. Uma garantia de fornecedor pode ser significativa para uma versão específica do serviço e um contrato. Um programa de formação pode ser adequado para o trabalho que as pessoas faziam quando o frequentaram. Nenhum destes registos se torna mau quando as suas condições mudam. Torna-se incompleto para uma nova decisão.

Esta é uma das razões pelas quais a revisão anual é simultaneamente útil e insuficiente. Uma data anual estabelece um ritmo mínimo e impede que os registos desapareçam indefinidamente numa unidade partilhada. Mas uma mudança importante pode acontecer amanhã. A DORA combina ambas as ideias ao exigir revisão regular pelo menos anualmente e avaliação de risco em cada mudança importante. Os dois relógios funcionam em conjunto: a revisão periódica deteta a deriva lenta; a revisão desencadeada deteta uma condição que já alterou a decisão.

A expiração deve estar ligada a afirmações, não apenas a documentos. Um documento pode conter várias afirmações com durações diferentes. Um diagrama de arquitetura pode permanecer em grande parte exato enquanto uma descrição de controlo de segurança mudou. Uma avaliação pode continuar a estabelecer uma capacidade restrita enquanto deixa de apoiar uma declaração de desempenho mais ampla. Uma política pode estar atual enquanto um proprietário nomeado não está. Quando uma equipa marca todo o ficheiro como atual ou obsoleto, perde estas distinções. A manutenção ao nível da afirmação dá mais trabalho. Também dá aos revisores a oportunidade de atualizar o que mudou sem reescrever a história.

Há aqui um benefício humano. As pessoas que herdam um sistema precisam de saber em que podem confiar. Um registo que diz "atual" sem data, âmbito ou proprietário entrega-lhes um problema de confiança disfarçado de documentação. Um registo que diz "avaliado para este fim, com este estado capturado, nestas condições, revisto nesta data, próxima revisão devida aqui" dá-lhes algo que podem inspecionar e questionar. Não torna o sistema seguro por declaração. Torna visível o limite do conhecimento existente.

A expiração também torna a reforma menos dramática. Um sistema não tem de ser um escândalo para ser retirado ou substituído. Um fornecedor pode terminar o suporte. Um modelo pode deixar de se adequar a um novo contexto linguístico ou político. O peso das provas pode exceder o valor de manter um percurso antigo. Pode existir uma alternativa mais segura. A organização pode decidir que a tarefa deve voltar a uma pessoa ou a um mecanismo mais simples sem IA. Um calendário de manutenção deve incluir um caminho de saída antes de o serviço se tornar difícil de remover. A retirada é uma ação de governação, não uma prova de que a governação falhou.

O que não deve expirar é a história. A organização deve preservar o que foi avaliado, decidido, alterado e observado, sujeito às regras aplicáveis de retenção, confidencialidade e proteção de dados. Preservar a história é diferente de tratar provas antigas como atuais. Uma apoia a aprendizagem e a responsabilização. A outra pode transformar um registo antigo numa garantia falsa. Bons arquivos lembram-se da diferença.

Um calendário é uma atribuição de autoridade

O artefacto de governação mais útil pode ser menos entusiasmante do que uma matriz de risco: um calendário com nomes ao lado. Quem revê o propósito. Quem lê o sinal de monitorização. Quem pode declarar que um limiar foi atingido. Quem pode suspender um percurso. Quem aprova uma mudança importante. Quem verifica as provas de verificação. Quem comunica com um fornecedor. Quem decide que uma avaliação antiga já não apoia a utilização continuada. Se a resposta a tudo isto for "a equipa de IA", a organização não atribuiu autoridade. Nomeou uma sala.

Autoridade precisa de independência suficiente para ser significativa e de proximidade suficiente para agir. Um conselho ou órgão de gestão pode deter a supervisão e os recursos. Um responsável operacional pode compreender o trabalho real. Um responsável técnico pode conhecer os limites do sistema. Um especialista em segurança ou privacidade pode identificar uma fronteira que outros não veem. Uma equipa virada para o cliente ou para o serviço público pode ver o dano antes de um painel de controlo o ver. Estes papéis não precisam de ser fundidos num único herói. Precisam de passagens de testemunho definidas e de uma forma de resolver divergências. O enfoque da NIS2 na aprovação e supervisão da gestão é útil aqui porque recusa a ficção conveniente de que a governação pode ser totalmente delegada enquanto a responsabilidade permanece no topo.

O limiar de escalada deve ser redigido numa linguagem que corresponda a uma decisão. «Escalar se a pontuação de anomalia exceder 0,8» pode ser tecnicamente necessário, mas não diz a uma instituição o que está em jogo. Um limiar melhor pode combinar sinal e consequência: escalar quando o sistema começa a afetar uma utilização fora do âmbito declarado; quando uma falha de controlo puder deixar uma pessoa afetada sem revisão; quando uma fonte ou dependência material mudar; quando as correções revelarem um padrão que a avaliação existente não cobriu; quando for comunicada uma preocupação grave de segurança, proteção ou direitos; quando um responsável ou recurso de recurso exigido deixar de estar disponível. Os limiares exatos variarão. A linguagem de decisão não deve variar.

A manutenção também precisa de orçamento. Isto é banal e decisivo. A monitorização consome tempo. Rever uma alteração consome capacidade técnica, jurídica e operacional. Ensaia um plano de incidente interrompe o trabalho normal. Atualizar uma explicação, um registo ou um programa de formação é trabalho. Quando a governação não tem um modelo operacional com pessoal, torna-se um imposto de emergência cobrado a quem primeiro notar o problema. Esse arranjo parece económico até ao primeiro evento difícil, quando a organização descobre que poupou o custo da preparação e comprou o custo da improvisação.

Há espaço para proporção. Uma ferramenta interna restrita com uma utilização clara e sem consequências pode precisar de um calendário mais leve do que um sistema que afeta o acesso ao trabalho, a serviços, a direitos ou à segurança. Mas mais leve não significa ausente. Pode ainda precisar de um responsável, de uma fronteira de finalidade, de um registo de alterações, de um percurso básico de incidentes e de uma condição de saída. A complexidade deve seguir a consequência e a incerteza, não a quantidade de entusiasmo disponível no arranque do projeto.

Um calendário de manutenção útil pode ser expresso em linguagem simples. Rever a finalidade quando a utilização, os utilizadores ou as consequências mudarem. Rever as dependências quando um fornecedor, um percurso de dados ou um serviço ligado mudar. Rever as provas de avaliação quando o modelo, a configuração ou as condições operacionais relevantes mudarem. Ensaia o percurso de incidente e de paragem num intervalo definido. Rever as atribuições de papéis quando a organização mudar. Publicar ou conservar um registo de alterações quando uma decisão tiver um efeito material. Testar o percurso de saída antes de o serviço depender dele. Nada disto promete que os erros não acontecerão. Promete que a organização tem uma forma de notar, decidir e aprender quando eles acontecem.

Uma pequena nota nossa

Na Dweve, o nosso Centro de Confiança descreve a monitorização como um registo público separado, e não como uma promessa de que um produto atingiu um estado permanente de conclusão. O seu material de monitorização publicado afirma que os sinais estão ligados a fronteiras de recolha declaradas, que as revisões identificam o modelo, o percurso, o estado e as provas relevantes, e que alterações materiais podem abrir revisão de avaliação, risco, incidente ou lançamento. O registo público de alterações também distingue factos atuais de controlos preparados e eventos futuros. Essas são descrições do nosso desenho operacional declarado, não garantia independente, resultado para o cliente ou alegação de que uma página pública resolve todas as questões de governação.

Essa fronteira é intencional. Consideramos que um registo de monitorização é útil quando diz aos leitores o que pode ser observado, o que permanece protegido, o que pode desencadear uma ação e onde será registada uma decisão material. O registo não pode julgar em nome das pessoas que operam um sistema. Pode tornar o julgamento mais fácil de inspecionar quando é feito.

A manutenção é a parte honesta

O lançamento é um momento útil. Cria uma razão para definir o propósito, avaliar riscos e assumir compromissos. Não é o momento em que a tecnologia deixa de encontrar o mundo. A governação torna-se credível depois, no trabalho repetido de descobrir se a decisão antiga ainda merece manter-se.

Esse trabalho precisa de um calendário porque as boas intenções têm uma meia-vida curta quando não têm uma data, um responsável e um caminho para a ação. Precisa de evidências porque a cor de um painel não é uma explicação. Precisa de autoridade porque monitorizar sem o direito de mudar qualquer coisa é observação com boa imagem. Precisa de história porque uma correção que não pode ser rastreada não pode melhorar de forma fiável a próxima decisão. E precisa de uma saída porque a operação continuada deve continuar a ser uma escolha, não um facto herdado.

A pergunta madura não é se uma organização consegue produzir um quadro de governação. Muitas conseguem. A pergunta é se, meses após a aprovação do documento, a organização ainda consegue dizer para que serve o sistema, o que mudou, que evidências o sustentam agora, quem pode pará-lo e o que acontece quando a resposta já não é clara. Se consegue, a governação está a ser mantida. Se não consegue, a organização pode ainda ter uma política. Simplesmente deixou de ter uma viva.

Fontes