Confiança e conformidade
Uma pessoa decide. O registro diz quem.
O que nosso software pode fazer sozinho, onde ele roda e o que ele deixa por escrito. Cada seção termina com links para a documentação pública que mostra isso, para que você possa conferir cada linha em vez de confiar na nossa palavra.
1 · Uma pessoa decide
Os agentes redigem. Uma pessoa com nome decide.
Os agentes da Runink leem registros e redigem rascunhos: um processo de sinistro, uma correção de código, uma publicação, uma resposta. O rascunho fica aguardando. Uma pessoa com nome aprova, edita ou rejeita, e o registro guarda quem foi e quando.
No Runink TIDE, essas decisões vão para uma cadeia de auditoria. Cada entrada é ligada à anterior, então uma entrada alterada, removida ou fora de ordem fica visível. Qualquer pessoa conectada ao console do TIDE pode clicar em Verify now para que a cadeia inteira seja conferida. A leitura das entradas em si fica restrita aos administradores que você indicar.
Duas coisas agem sozinhas, e preferimos que você leia isso aqui a descobrir depois:
- O FACE cuida do próprio funcionamento. Quando uma parte do FACE para de responder, ele pode reiniciá-la, isolar uma dependência que falha repetidamente, desfazer a alteração mais recente ou adicionar capacidade. Ele só escolhe dessa lista fixa. Nunca apaga dados, nunca desliga uma máquina e nunca desativa um controle de segurança. Na dúvida, avisa uma pessoa em vez de agir. Um operador pode desligar a parte automática.
- O classificador de issues do TIDE coloca etiquetas nas issues novas. Ele só escolhe entre as etiquetas que o repositório permite, e só quando uma verificação independente concorda. Uma pessoa pode mudá-las a qualquer momento, e decide quem cuida da issue.
Todo o resto espera por uma pessoa.
2 · Salvaguardas
Cada agente trabalha dentro de regras escritas.
Cada agente que chama um modelo tem um juiz de políticas à sua frente. O juiz confere um pedido contra regras escritas antes que o modelo o veja, e confere o que o agente escreve antes que seja enviado ou publicado. Um pedido que viola uma regra é recusado, e a recusa fica registrada.
As regras de segurança seguem o OWASP Top 10 for LLM Applications, a lista publicada das formas mais comuns de atacar uma aplicação de IA. Elas cobrem tentativas de passar por cima das instruções do agente (a injeção de prompt), tentativas de extrair segredos ou outras informações sensíveis e pedidos para chegar a lugares onde o agente não tem nada a fazer.
Registros, páginas da web e documentos que um agente lê são tratados como dados, nunca como instruções. Uma linha de um registro de frete que diz "ignore suas regras" é lida como parte desse registro. Quando um agente propõe uma ação, uma segunda verificação lê as evidências que a execução reuniu. Se ela discordar, a ação fica retida. Se não conseguir decidir, ela diz isso em vez de deixar passar.
3 · Onde os modelos rodam
Modelos abertos, com nome, sem um fornecedor de IA no meio.
FACE, TIDE e PULSE rodam seus modelos onde o produto roda. Instale em um Runink Server nas suas instalações ou na sua própria conta na nuvem, e os modelos também rodam na sua infraestrutura. Escolha as máquinas compartilhadas da Runink, e eles rodam nas nossas. Nos dois casos, nenhum serviço de IA de terceiros é chamado: seus registros, os prompts montados a partir deles e as respostas não vão para nenhum fornecedor de modelos.
O LUNA, nosso aplicativo de companhia pessoal, roda seus modelos em servidores operados pela Runink. Ele também não chama nenhum serviço de IA de terceiros.
Os modelos são abertos, e nós os indicamos com o autor e a licença:
Qwen3.6-35B-A3B
O modelo geral, usado pela maioria dos agentes. Criado pela Qwen, com licença Apache-2.0.
Qwen3-Coder-30B-A3B
O modelo de código, para revisar e redigir código. Criado pela Qwen, com licença Apache-2.0.
Qwen3-VL-8B-Instruct
O modelo de visão, para páginas digitalizadas e fotos. Criado pela Qwen, com licença Apache-2.0.
Cada agente tem uma ficha de modelo pública: o que faz, o que lê, o que uma pessoa continua decidindo, em qual modelo roda, onde roda e onde para.
4 · Seus dados, separados
O registro de outra pessoa? "Não encontrado".
Os dados de cada pessoa, e os de cada cliente, ficam separados no servidor. Os dados que um pedido pode alcançar dependem da identidade verificada no login, não do que o próprio pedido diz.
Peça um registro que pertence a outra pessoa e a resposta é "não encontrado", a mesma de um registro que não existe. A resposta nem sequer confirma que o registro está lá.
O FACE vai um passo além: cada cliente tem sua própria instância do FACE, então os dados de um cliente nunca dividem uma instância com os de outro.
Leia as evidências (em inglês)
5 · Desconhecido não é zero
Um número que falta aparece como faltando.
Quando nosso software não consegue ler um número, ele diz isso, com o motivo. Ele não desenha um zero e não chuta. Uma verificação que não pôde rodar aparece como "não verificado", nunca como aprovada. Um campo que ele não conhece fica vazio, não é preenchido.
Seguimos a mesma regra. Esta página não traz estatísticas, e as fichas de modelo também não: nenhuma mostra uma nota de avaliação, porque nenhuma foi publicada.
6 · Versões assinadas
Uma pessoa assina cada versão, longe da compilação.
As versões e os pacotes do Runink River são assinados com uma única chave de publicação. O responsável pelas versões guarda a chave privada offline. Ela nunca fica na CI e nunca é guardada como segredo de um repositório.
As máquinas de compilação só produzem arquivos não assinados e seus checksums. O responsável compara esses arquivos com uma compilação própria e depois assina. Antes que uma versão seja publicada, uma etapa automática confere a assinatura e os checksums. A CI verifica; ela nunca assina.
O arquivo KEYS público é a referência. Confira a chave por esta impressão digital, nunca pelo nome:
95C0 A7B9 7D54 7413 E426 60DD B06F E756 26F1 5BF3
Leia as evidências (em inglês)
7 · As normas com que nos alinhamos
Nossos próprios controles, relacionados a cinco normas.
Mantemos um índice escrito dos nossos próprios controles de segurança: como os dados são criptografados em trânsito e em repouso, como o login recusa por padrão, como os dados de cada cliente ficam separados, como os segredos são tratados, entre outros. Cada controle indica o código que o executa, e cada um está relacionado às partes destas normas que ele atende:
- SOC 2
- ISO/IEC 27001
- ISO 31000
- ISO/IEC 42001
- PCI DSS v4.0
A Runink não é certificada em nenhuma dessas normas; alinhamento não é certificação.
Um agente de evidências lê o índice e confere se o código indicado por cada controle continua lá. Ele registra evidências, nunca um veredito. Qualquer declaração formal em relação a uma dessas normas viria de um auditor independente, não de nós nem do nosso software.
Leia as evidências (em inglês)
8 · Relatar um problema de segurança
Encontrou algo? Conte para nós em particular.
Por favor, não abra uma issue pública para um problema de segurança. Escreva para:
security@runink.org
Você pode abrir no seu aplicativo de e-mail ou copiar o endereço acima. Para criptografar seu relato, use a chave de publicação da seção 6 e confira antes a impressão digital. Conte o que foi afetado e em qual versão, o que um atacante poderia fazer e como reproduzir, se puder. Para o Runink River, você também pode usar o botão de relato privado na aba Security do repositório.
Leia as evidências (em inglês)
Com quem você trabalharia
A Runink é dirigida pelo fundador. A pessoa na primeira reunião é a mesma que desenhou aquilo que está em discussão.
Dan Paes
Diretor-executivo e fundador técnico
Dan Paes passou mais de vinte anos dentro da empresa dos outros, conduzindo programas de transformação digital e de modernização em larga escala para organizações globais. Do tipo demorado: o que se substitui é aquilo em que o negócio está rodando naquela manhã, e o trabalho é julgado por se alguma coisa quebrou.
Ele fundou a Runink e a dirige como diretor-executivo. Fundador técnico é a metade mais útil desse título: ele define a arquitetura e trabalha no código, de modo que quem responde a uma pergunta de arquitetura numa primeira reunião é quem decidiu a resposta, e a distância entre uma pergunta e uma mudança é curta.
É também por isso que a plataforma tem o formato que tem. Ela roda em hardware que o cliente controla, e o raciocínio sobre os dados dele fica ali. Essa é a maneira mais cara de construir e fecha o caminho conveniente, que é o tipo de decisão que precisa ser resolvida por quem é dono da arquitetura em vez de ficar onde possa ser negociada em silêncio.
Ele é Embaixador FINOS. A FINOS é a Fintech Open Source Foundation, parte da Linux Foundation, e o trabalho ali é interoperabilidade entre instituições que compartilham um mercado mas não a infraestrutura e nunca os dados. É o mesmo problema para o qual esta plataforma aponta, discutido em aberto, diante de gente que diz quando está errado.
-
Mais de 20 anos
Transformação digital e modernização em larga escala para grandes empresas.
-
Diretor-executivo e fundador técnico
Runink. Define a arquitetura e escreve código nela.
-
Embaixador FINOS
Fintech Open Source Foundation, um projeto da Linux Foundation. Interoperabilidade open source, em público.
Confira qualquer um destes pontos
Um próximo passo
Peça para mostrarmos qualquer linha desta página.
Meia hora com quem cuida de segurança ou conformidade do seu lado. Escolha uma seção: abrimos o software funcionando e o registro que ele mantém, não um slide sobre o assunto.
Agende uma consulta