ALCOA+ na prática: o que integridade de dados realmente exige dos seus sistemas

Todo manual da qualidade cita o ALCOA+. Bem menos gente o traduz em decisões sobre como os sistemas são construídos e configurados — que é exatamente de onde vêm os apontamentos de auditoria. Um inspetor não autua ninguém por não recitar a sigla; ele autua porque um registro não pôde ser atribuído, um carimbo de tempo não refletia a realidade, ou um valor original foi sobrescrito e ninguém conseguiu provar o contrário.

Este é um percurso por cada princípio como requisito de sistema: o que ele exige, como costuma falhar num chão de fábrica real, e o que um sistema precisa fazer para satisfazê-lo.

De onde vem o ALCOA+

O ALCOA foi cunhado no FDA nos anos 1990 como um recurso de memória para descrever o que é um bom registro. O "+" veio depois, por meio de orientações do MHRA e do PIC/S, acrescentando quatro atributos que os cinco originais implicavam mas não declaravam. Hoje o arcabouço está por trás do FDA 21 CFR Parte 11, do Anexo 11 das GMP europeias e das orientações de integridade de dados que a maioria dos reguladores publica.

Ele se aplica igualmente a registros em papel e eletrônicos. Mas o papel falha nesses testes de formas visíveis e lentas, enquanto sistemas eletrônicos falham de formas invisíveis e rápidas — e é por isso que o desenho do sistema carrega tanto peso.

Os cinco originais

Atribuível — quem fez isso, e quando

Todo registro precisa remeter à pessoa ou ao instrumento que o produziu. A falha comum não é fraude; é conveniência. Logins compartilhados num terminal de chão de fábrica, um supervisor lançando leituras em nome do operador, uma exportação de datalogger sem indicação de quem a gerou.

Sistemicamente isso significa contas individuais, nenhuma credencial compartilhada, e valores gerados por máquina atribuídos ao instrumento e não a quem estava logado no momento. Onde uma ação humana carrega peso regulatório, a assinatura eletrônica deve ser distinta do login — um PIN de assinatura, aplicado no ato, com o significado declarado.

Legível — legível agora e daqui a dez anos

Legibilidade não é só caligrafia. Para registros eletrônicos, significa que o dado permanece legível e interpretável por todo o período de retenção, incluindo os metadados que lhe dão sentido. Um CSV de carimbos de tempo e números cujos nomes de tag só existiam num SCADA desativado deixou de ser legível em qualquer sentido útil.

Contemporâneo — registrado quando aconteceu

O registro precisa ser feito no momento da atividade. Este é o princípio que dados de processo em papel quase nunca satisfazem: o operador lê um mostrador às 14:32, anota num rascunho e transcreve para o registro de lote no fim do turno. O valor pode estar certo; o registro não é contemporâneo, e o carimbo de tempo é ficção.

Capturar na fonte é a única correção estrutural. Quando um historiador de processo registra a leitura conforme o dispositivo a emite, o carimbo de tempo é o do evento e não o da digitação — e o registro de lote pode referenciar aquele valor em vez de uma transcrição dele.

Original — a primeira captura, preservada

O registro original, ou uma cópia fiel certificada, precisa ser preservado. Na prática é aqui que "nós guardamos o relatório consolidado" vira apontamento. Se o evento bruto foi descartado, ou silenciosamente corrigido, ou existe apenas como agregado, o original se perdeu.

Gravação sem sobrescrita do evento que chega responde a isso diretamente: o dado bruto é mantido como recebido e não é editado pela aplicação, de modo que qualquer número num relatório pode ser rastreado até o que o instrumento efetivamente enviou.

Exato — correto, e demonstravelmente

A exatidão cobre tanto o valor quanto os metadados ao seu redor. Protocolos industriais carregam um código de qualidade junto da leitura por um motivo: uma temperatura de 4,4 °C vinda de um sensor que reporta qualidade ruim não é um registro exato da câmara fria, é um registro exato de um problema no sensor. Sistemas que descartam códigos de qualidade na ingestão destroem justamente a evidência que distingue os dois casos.

O "mais": completo, consistente, duradouro, disponível

Os quatro acréscimos fecham as lacunas que os cinco originais deixam abertas.

• Completo — incluindo reanálises, corridas que falharam e leituras que não puderam ser decodificadas. Um sistema que descarta silenciosamente eventos malformados produz um conjunto de dados arrumado e um registro incompleto. Eventos com falha devem permanecer visíveis e ser reprocessáveis quando a causa for corrigida.
• Consistente — registros em sequência, com carimbos de tempo que concordam entre sistemas. Tempo sincronizado é um controle de integridade de dados, não um capricho de TI; dois sistemas em deriva tornam discutível qualquer reconstrução dos fatos.
• Duradouro — durável por todo o período de retenção, em mídias e formatos que sobrevivam a ele. Uma planilha num diretório compartilhado não é duradoura, diga o que disser a política de retenção.
• Disponível — recuperável para revisão ao longo de todo esse período. Um dado que existe mas leva três semanas e um especialista para ser extraído falha no único teste que conta, que é a inspeção.

A trilha de auditoria é onde tudo se decide

Boa parte do ALCOA+ se reduz a uma pergunta que o inspetor pode fazer diretamente: você consegue me mostrar tudo o que aconteceu com este registro?

Uma trilha de auditoria que responde a isso registra não apenas a alteração, mas quem a fez, quando, e qual era o valor anterior. Encadear as entradas com hash, de modo que cada uma referencie a anterior, acrescenta a propriedade que mais importa: adulteração retroativa se torna detectável, porque alterar uma entrada antiga quebra a cadeia dali em diante. Sem isso, uma trilha de auditoria afirma a história em vez de evidenciá-la.

Se a trilha de auditoria pode ser editada sem deixar rastro, todo o resto da lista é questão de confiança, não de prova.

O que isso significa ao especificar um sistema

Transformar o arcabouço em requisitos é mais útil do que citá-lo. Uma especificação defensável pergunta, no mínimo:

1. O valor é capturado na fonte, com o carimbo de tempo de origem e o código de qualidade preservados?
2. O evento bruto é armazenado sem sobrescrita, e a retenção está explicitamente configurada?
3. Toda alteração de configuração e de dado é registrada numa trilha de auditoria com verificação de integridade?
4. As contas são individuais, as permissões são por papel, e a assinatura eletrônica é distinta das credenciais de acesso?
5. Eventos com falha ou não decodificáveis ficam visíveis e recuperáveis, em vez de descartados?
6. O dado pode ser recuperado, com contexto, por alguém que não seja quem construiu o sistema?

Essas perguntas pertencem à sua validação de sistemas computadorizados segundo o GAMP 5, e não a uma revisão de compliance separada depois do go-live. Validar um sistema cuja arquitetura não consegue satisfazê-las é uma forma cara de documentar uma lacuna.

Dado de processo e registro de execução

Esses requisitos se dividem por uma linha natural: o que registra a medição, e o que registra o ato de usá-la. O NEO PI cuida do dado de processo: captura na fonte por OPC-UA, MQTT e LoRaWAN, eventos brutos gravados sem sobrescrita, códigos de qualidade preservados, trilha de auditoria encadeada por hash, e uma API de leitura que permite ao registro de lote referenciar um valor em vez de uma transcrição dele. O NEO EBR cuida do registro de execução: sequência forçada, controles em processo que leem do historiador, e assinatura eletrônica nas etapas que carregam peso regulatório.

Os dois se inserem numa postura mais ampla de conformidade digital — e, se você ainda está no começo desse caminho, o roteiro de digitalização cobre a sequência usual, enquanto o monitoramento ambiental costuma ser o ponto de partida menos disruptivo.