Enterprise
Um registo de auditoria apenas de acréscimo para o desenvolvimento assistido por IA
Cada pedido, merge, deploy e ação administrativa, registados apenas por acréscimo — para que 'quem fez o quê, e quem o aprovou' tenha uma resposta que os seus auditores conseguem ler.
O Ciao mantém um registo de auditoria apenas de acréscimo que abrange pedidos, merges, deploys e ações administrativas. Ao contrário de ferramentas de desenvolvimento que só registam commits, o registo capta a nova pergunta da era da IA — o que foi pedido à IA, o que mudou em resultado disso, e que humano o reviu — com o Guardrails a registar a revisão humana atrás de cada merge. O registo pode ser exportado para revisão de auditoria e demonstrado ao vivo durante a avaliação.
Publicado 2026-07-03 · Última atualização 2026-07-03
'Quem fez o quê' agora inclui a IA
A gestão de mudança tradicional audita três artefactos: o ticket, o commit e a aprovação. O desenvolvimento assistido por IA acrescenta um quarto que a maioria das ferramentas ignora — o pedido. Quando um pedido em linguagem simples pode produzir uma alteração de produção, o próprio pedido faz parte do registo da mudança, e um registo de auditoria que começa no commit já perdeu o início da história.
O Ciao regista toda a sequência. Os pedidos são eventos de primeira classe; os merges transportam o registo de revisão do Guardrails — que política se aplicou, que humano reviu, o que foi aprovado; os deploys e as ações administrativas completam o quadro. O registo é apenas de acréscimo: as entradas acumulam-se, e a história que os seus auditores leem é a história que aconteceu. Nada na sequência precisa de ser reconstituído a partir de exportações de conversas ou capturas de ecrã depois do facto.
Para um CISO, isto converte uma pergunta incómoda — 'como controlam o que a IA altera?' — numa pergunta revisível: puxe o registo e leia exatamente o que foi pedido, o que mudou, quem o aprovou e quando foi lançado. Esta única capacidade tende a deslocar uma plataforma de desenvolvimento com IA da coluna das 'exceções a explicar' de uma revisão de risco para a coluna dos 'controlos a referenciar', porque poucas histórias de gestão de mudança no resto do parque tecnológico começam tão cedo quanto o próprio pedido.
O que é registado
Quatro classes de eventos, um só registo — registadas em sequência, não montadas depois do facto:
- Pedidos — Os pedidos em linguagem simples feitos à plataforma — o verdadeiro início de cada alteração, captado em vez de perdido numa janela de conversa.
- Merges com contexto de revisão — O Guardrails mapeia o código em áreas de negócio, deteta alterações arriscadas, aplica políticas em linguagem simples e regista a revisão humana — deixando um registo de auditoria atrás de cada merge.
- Deploys — O que foi lançado e quando, ligando as alterações aprovadas àquilo que está efetivamente em execução perante os utilizadores.
- Ações administrativas — Alterações de identidade, acesso e configuração — incluindo eventos de provisionamento do SSO e do SCIM — para que as revisões de acesso e as revisões de mudança recorram ao mesmo registo.
- Apenas de acréscimo por conceção — O registo acumula-se; as entradas não são editadas no local. O que os revisores leem é a sequência tal como ocorreu.
Exportação e revisão
Evidência que não se consegue extrair é evidência que não se tem. O registo pode ser exportado para revisão de auditoria, para que a sua equipa traga registos para os seus próprios papéis de trabalho e processo de retenção, em vez de capturar o ecrã da interface de um fornecedor. Durante a avaliação, peça duas coisas: uma demonstração ao vivo em que escolhe uma alteração real e a segue de ponta a ponta, e uma exportação dessa mesma sequência para que os seus auditores vejam o formato com que realmente trabalhariam. Pergunte também quem pode executar exportações e como os próprios eventos de exportação ficam registados — uma boa história de registo inclui a história de acesso ao próprio registo.
Para a resposta a incidentes, o mesmo registo serve um propósito diferente. Quando algo se avaria ou parece errado, os responsáveis reconstituem a sequência desde o pedido até ao deploy, sem depender da memória de ninguém sobre o que foi pedido e aprovado. A evidência que satisfaz um auditor na revisão trimestral é a evidência que encurta a linha temporal de um incidente na semana má.
Como decorre um pedido de auditoria
Uma demonstração concreta, usando o registo da mesma forma que os seus auditores usariam:
1. Delimite a pergunta
Um auditor pergunta sobre uma alteração: quem a iniciou, o que tocou, quem a aprovou, quando chegou à produção.
2. Puxe o registo
Localize a sequência — pedido, alteração resultante, política e registo de revisão do Guardrails, evento de deploy.
3. Mostre a revisão
O registo do merge mostra a política em linguagem simples que se aplicou e a revisão humana que o Guardrails registou, respondendo diretamente à pergunta sobre a aprovação.
4. Exporte a evidência
Exporte os registos relevantes para os papéis de trabalho da auditoria, para que a conclusão assente em registos e não em recordação.
5. Feche o ciclo
Como as ações administrativas estão no mesmo registo, as perguntas de seguimento sobre quem tinha acesso na altura são respondidas a partir da mesma fonte.
Tipos de evento e porque importam aos revisores
| Tipo de evento | O que é registado | Porque importa aos revisores |
|---|---|---|
| Pedido | O pedido em linguagem simples feito à plataforma | A verdadeira origem de uma alteração assistida por IA |
| Merge | Deteção de alterações arriscadas, política aplicada, revisão humana registada | Evidência de aprovação atrás de cada merge |
| Deploy | O que foi lançado e quando | Liga as aprovações à realidade da produção |
| Ação administrativa | Alterações de identidade, acesso e configuração | Revisões de acesso e evidência de alterações privilegiadas |
Notas de verificação
O registo é um controlo que pode observar a funcionar: durante a avaliação, faça uma alteração através da plataforma e depois encontre-se a si próprio no registo. Para evidência escrita, os relatórios SOC 2 Type II estão disponíveis sob NDA, e o dossiê de segurança — a pedido através da página de contacto — cobre a arquitetura de registo e os detalhes de retenção. Se o seu framework de auditoria tiver requisitos particulares de retenção ou formato, coloque-os por escrito junto da equipa enterprise durante as compras.
Um hábito que vale a pena adotar de equipas que auditam bem: escolha uma alteração real por mês e siga-a de ponta a ponta como exercício. Isso mantém o músculo da auditoria ativo, revela lacunas enquanto ainda são baratas de corrigir, e transforma a auditoria anual na repetição de algo rotineiro em vez de uma correria de última hora.
Perguntas frequentes
As entradas do registo de auditoria podem ser editadas ou eliminadas por um administrador?
O registo é apenas de acréscimo por conceção — as entradas acumulam-se em vez de serem editadas no local. Para o detalhe de arquitetura por trás dessa propriedade, peça o dossiê de segurança e, sob NDA, o relatório SOC 2 Type II que cobre os controlos relevantes.
Os pedidos feitos à IA fazem mesmo parte do registo de auditoria?
Sim. O registo abrange pedidos, merges, deploys e ações administrativas, para que o registo de uma alteração comece no pedido e não no commit. Durante a avaliação, pode seguir um pedido até ao respetivo deploy.
Durante quanto tempo são retidos os registos de auditoria?
Os detalhes de retenção pertencem a um documento escrito, não a uma página de marketing — estão cobertos no dossiê de segurança e podem ser tratados no seu contrato. Indique o requisito de retenção do seu framework durante as compras e obtenha a resposta documentada.
Podemos puxar o registo para as nossas ferramentas de SIEM ou GRC?
O registo pode ser exportado para revisão de auditoria. A ingestão na sua stack específica de SIEM ou GRC é uma questão de integração — descreva o seu pipeline à equipa enterprise e confirme o fluxo de trabalho durante a avaliação, em vez de o presumir.
Quem pode ler o registo de auditoria?
O acesso ao registo é regido pelo controlo de acesso baseado em funções, para que a visibilidade de auditoria seja uma função que o seu workspace atribui deliberadamente. As próprias alterações de acesso são ações administrativas — registadas no mesmo registo a que concedem acesso.