modelo 01 · treinado
COS Sentinel
Um só lugar para as rotinas, os registros e os relatórios de uma operação de segurança.
- Estado
- Em implantação — versão de testes com os operadores
- Papel
- Ideia e desenvolvimento — por iniciativa própria
Filme de apresentação
experiênciaO problema
A central de segurança convivia com dores do dia a dia: rotinas feitas de jeitos diferentes, informações espalhadas e pouca padronização entre turnos. Ninguém me pediu um sistema — eu vi essas dores de perto, no meu próprio trabalho, e decidi resolver. O COS Sentinel nasceu para facilitar e padronizar a operação da COS.
Contexto e restrições
Desenvolver sistemas não era a minha função. Comecei por fora, no meu tempo, como um projeto pessoal. A central gostou, e hoje o COS Sentinel está em implantação: a primeira versão oficial de testes já está nas mãos dos operadores.
Nasceu num contexto corporativo de segurança. Tudo o que aparece neste case está sanitizado ou aguardando autorização de publicação.
É um sistema interno, com dados da empresa: roda num servidor dentro da rede e só é acessado pela rede interna ou por VPN.
Desenvolvi fora do horário, no meu notebook, só com dados de teste. As informações da empresa entram apenas no computador e no servidor de dentro da rede.
O sistema
Operações de segurança dependem de rotinas e informações que precisam estar em um só lugar. O COS Sentinel centraliza tudo em um único sistema web, organizado em quatro módulos: Central, Controle de PA, Histórico / RO e Relatórios.
módulo 01 de 04
Central
Registro guiado das ocorrências em 6 etapas, com protocolo e acompanhamento até o fim. Registre, acompanhe, tenha controle.
Por dentro do sistema
experiênciaO sistema rodando de verdade, num banco de testes descartável. Os registros que aparecem nas telas — ocorrências, pessoas, locais e atendimentos — são fictícios, criados só para esta demonstração.
Início
O plantão numa olhada: o que abriu hoje, o que está em andamento, o que é crítico, os próximos PAs e as últimas ocorrências.
As telas
experiênciaTelas reais do filme. Arraste para o lado e clique em uma para ver aquele momento no vídeo.
Papel
Ideia e desenvolvimento — por iniciativa própria
Arquitetura
engenhariaL1 · Interface
Telas renderizadas no servidor; componentes de cliente só onde a tela precisa reagir na hora, como o PA em tempo real.
L2 · Entrada
Server actions e rotas de API são as únicas portas para ler ou gravar dados.
L3 · Acesso
Sessão e perfil conferidos no servidor em toda chamada — esconder um botão nunca substitui a permissão.
L4 · Domínio
Registro e comunicação · Controle de PA · Histórico / RO · Relatórios · diretórios e contatos
L5 · IA local
Corrige só o texto livre do operador; um verificador confere cada correção antes de aceitar.
L6 · Dados
Esquema em Drizzle sobre PostgreSQL 16.
Visão de alto nível, conferida no código do sistema. Endereços, integrações internas e configurações da empresa ficam de fora.
Stack e motivos
engenharia- Next.js 16App Router · server components · server actions
- As telas e as ações rodam no servidor, então o acesso ao banco e as regras nunca chegam ao navegador e não existe uma API pública para proteger.
- PostgreSQL 16Banco de dados principal
- Ocorrências, comunicações e atendimentos de PA ficam ligados entre si e consistentes, com o histórico de cada mudança.
- Drizzle ORMSchema · queries tipadas
- O esquema do banco vive no código em TypeScript, e o mesmo esquema monta o banco descartável usado nos testes.
- Better AuthLogin · sessões · perfis
- Login dentro do próprio sistema, com a mesma conta da rede da empresa, e cinco perfis de acesso, de operador a superadministrador.
- IA local (Ollama · Qwen3 4B)Revisão do texto do operador
- Roda no próprio servidor, sem mandar nenhum relato para fora da rede. O modelo foi escolhido comparando quatro opções em relatos escritos do jeito que o operador digita.
- Tailwind CSSInterface
- Um vocabulário visual pequeno e consistente para telas operacionais densas, nos temas claro e escuro.
Como funciona
engenharia- 01
O operador conta o que aconteceu no registro guiado; o sistema valida os campos e avisa o que está faltando.
- 02
Um glossário da central corrige, sem IA, o que é previsível: abreviações, siglas, acentos e horários.
- 03
A IA local corrige só o texto livre. Códigos, horários e números são protegidos antes e voltam intactos depois.
- 04
Um verificador confere cada correção: se mudar um fato, um nome ou uma negação, ela é recusada e o texto volta como foi digitado.
- 05
O código monta a mensagem e o relatório sempre no mesmo modelo; o operador revisa e registra, e o PA começa a contar o SLA.
Trade-offs e lições
IA no próprio servidor em vez da nuvem. Os relatos têm informações internas, e mandar isso para uma IA na nuvem seria expor os dados da empresa. O preço é a qualidade: um modelo pequeno, rodando num servidor modesto, erra bem mais do que os grandes da nuvem.
Com uma IA pequena, não dá para confiar só nela. O que é previsível virou regra fixa, sem IA; os códigos e horários ficam protegidos; e toda correção passa por um verificador antes de valer. Se ela errar, o texto volta exatamente como o operador escreveu.
Resultados
Os operadores estão testando e se familiarizando com o sistema. Atualizo o Sentinel quase todo dia, com melhorias que saem do retorno deles. O próximo passo é a homologação: ser reconhecido pela área de cibersegurança como sistema oficial da empresa.
Próximo modelo — 02