Pular para o conteúdo
Para empresas que querem crescer com controle

Um sistema para operar sua empresa com IA.

Vendas, marketing, atendimento, operação, financeiro e inteligência trabalhando sobre o mesmo contexto — para sua empresa ganhar escala sem perder controle.

Sua empresa inteira. Uma operação. IA trabalhando.

Para empresas de qualquer setor que querem crescer com estrutura, controle e inteligência.

Painel ilustrativo do Sistema Centriu com sete frentes trabalhando: atendimento, comercial, operação, agentes, inteligência, conteúdo e marketing. Cada frente mostra o trabalho concluído ou o próximo passo.

Representação ilustrativa do trabalho em execução

O problema

Sua empresa não deveria operar em pedaços

Não é falta de ferramenta. É que cada ferramenta resolve um pedaço, e ninguém é dono do todo. O custo disso não aparece numa fatura — aparece no mês seguinte.

  • Sistemas que não se falam

    O mesmo dado é digitado de novo — e cada cópia conta uma história diferente.

  • Dados duplicados

    Ninguém sabe qual versão é a verdadeira na hora de decidir.

  • Conversas perdidas

    O cliente repete o contexto a cada canal e a cada pessoa.

  • Tarefas espalhadas

    O trabalho vive em planilhas, mensagens e na memória de alguém.

  • Decisões sem contexto

    A escolha é feita com o recorte que estava à mão, não com o que importava.

  • Automações desconectadas

    Cada ferramenta automatiza um pedaço e ninguém enxerga o todo.

Nenhum desses problemas se resolve comprando mais um software. Eles se resolvem quando a operação inteira passa a trabalhar sobre o mesmo contexto.

A resposta

Tudo trabalha sobre o mesmo contexto.

A Centriu não é uma coleção de produtos. É uma plataforma em que clientes, áreas e agentes leem e escrevem no mesmo lugar.

Cliente 360

Um contexto, não vários cadastros

Cada conversa, tarefa, campanha, cobrança e decisão fica ligada ao cliente e à operação — não a um sistema isolado.

  • Clientes
  • Comercial
  • Atendimento
  • Operação
  • Financeiro
  • Marketing
  • Inteligência
  • Agentes
  • Consultoria

As áreas abaixo são partes da mesma operação, não produtos separados. Elas compartilham conta, permissões e histórico.

IA que trabalha — não um chatbot ao lado

A inteligência artificial da Centriu participa da operação: entende contexto, prepara trabalho, executa rotinas e pede aprovação quando importa.

Entende o contexto

Lê a operação, o cliente e o histórico antes de propor qualquer coisa.

Prepara o trabalho

Redige, organiza, calcula e deixa pronto para revisão humana.

Executa rotinas

Roda o que é repetitivo dentro dos limites definidos pela empresa.

Recomenda a próxima ação

Cruza áreas, identifica prioridade e mostra o motivo da recomendação.

Pede aprovação

O que é sensível passa por uma pessoa antes de valer. Sem exceção silenciosa.

Mantém histórico e aprende

Registra o que aconteceu e usa o resultado para melhorar a próxima decisão.

O que a Centriu faz

Uma plataforma, várias frentes de trabalho. Tudo no mesmo contexto, com a IA participando do que dá para acelerar.

Comercial

CRM, pipeline, oportunidades, propostas, follow-up e automações.

Atendimento

WhatsApp, Instagram, Messenger, chat do site e e-mail no mesmo contexto.

Operação

Tarefas, responsáveis, prazos, aprovações, agenda e capacidade.

Financeiro

Contas, cobranças, caixa, fiscal, margem, IR, orçamento e inteligência econômica.

Marketing

Planejar, produzir, aprovar, publicar e medir conteúdo e campanhas.

Inteligência

Painéis, alertas, previsões, recomendações e leitura executiva.

Agentes

Rotinas executadas continuamente pela IA com controle e aprovação.

Consultoria

Diagnóstico, estratégia, transformação, acompanhamento e especialistas.

Para quem é

Para empresas que querem crescer — e crescer certo.

A Centriu faz sentido quando o volume aumenta e a estrutura precisa acompanhar. Não é sobre setor nem tamanho: é sobre a operação conseguir sustentar o próximo estágio.

As vendas crescem, mas o processo não acompanha.

As áreas trabalham separadas e o cliente sente.

A operação depende de pessoas específicas.

O financeiro ficou complexo e o caixa perde visibilidade.

O atendimento cresce em volume e em canais.

A IA entra sem contexto, controle ou histórico.

Se a empresa ainda não começou a crescer, a Centriu também ajuda a preparar a estrutura para o primeiro salto.

Ver a Centriu funcionando
Consultoria

Tecnologia sozinha não resolve uma operação mal desenhada.

A Centriu combina tecnologia, inteligência, método e acompanhamento. A consultoria diagnostica, desenha, implanta e acompanha — com evidências, não com apresentação.

A participação de especialistas depende da solução e do contrato. Não é um item incluído automaticamente em toda contratação, e não prometemos acompanhamento humano ilimitado.

Veja a Centriu funcionando na sua operação

Uma conversa para entender onde a sua operação perde tempo, dinheiro ou capacidade — e o que a Centriu faria primeiro.

Pular para o conteúdo

problema

Internal Support-Panel Tax-Data Firewall Automation: Three Layers, Because the First Two Will Eventually Fail

Centriu's own internal operations team needs to run the Income Tax module as a product. They manage licenses, track cost, investigate failures, review quality, and publish versions. This work must not require or permit looking at anyone's actual tax content. The single backend function for that internal panel has three independent layers. This is because each layer alone will eventually fail. The first is a structural layer. The database tables this function can query have no column for storing tax content. This is true no matter what the application code does. The second is an allowlist layer. Only a positive, clear list of field names can pass through to the panel. So, a new column added to another table tomorrow is hidden by default. It is not shown by default. The third is an output-verification layer. It runs on the finished response, ready to send. It checks for banned field names and for CPF or CNPJ-shaped patterns. If anything matches, it refuses to send the response at all. It does not try to remove the bad part and send the rest. Every response from this function goes through the same single function on its way out. There is no other way around any of the three layers.

Internal Support-Panel Tax-Data Firewall Automation: Three Layers, Because the First Two Will Eventually Fail

A single filter is a single point of failure, no matter how well it's built

Building one careful, well-tested filter that removes sensitive fields before data reaches an internal tool is genuinely good engineering. But it puts all the protection in one place. Any single place can fail. A new field might be added that the filter doesn't know about. A different code path might create a response without using the filter at all. Or the filter itself might have a bug nobody has found yet. A system that needs one mechanism to be perfect forever is taking a much bigger risk. A system that expects any one mechanism to eventually have a gap is safer. It builds a truly independent second and third check for that moment.

  • Building one careful, well-tested filter that removes sensitive fields before data reaches an internal tool is genuinely good engineering. But it puts all the protection in one place. Any single place can fail. A new field might be added that the filter doesn't know about. A different code path might create a response without using the filter at all. Or the filter itself might have a bug nobody has found yet. A system that needs one mechanism to be perfect forever is taking a much bigger risk. A system that expects any one mechanism to eventually have a gap is safer. It builds a truly independent second and third check for that moment.

How Centriu Gauge built a boundary designed to survive its own future mistakes

The backend function for Centriu's internal operations panel for the Income Tax module states its design idea directly in its header comment. It is worth repeating almost word for word because the reason is the main point. This function exists so Centriu can run the product. This includes licenses, cost, failures, quality, versions, and incidents. It does this without reading anyone's income tax information. It uses three boundary layers. All three must exist.

The first layer is structural. It is not a rule. The specific database tables this function can query simply have no column that can hold tax content. This was a planned database design choice from an earlier change. It is not a check that runs when the program is active, which could be bypassed or forgotten. The second layer is an allowlist. This is a single list of every field name the panel can show. It is applied to a response object at any level of nesting. The choice to build this as a positive list, rather than a list of fields to remove, is planned. It is explained directly in the code's own comment. A list of fields to remove protects only the fields someone remembered to write down. It fails silently on a fourth, forgotten one. A list of fields allowed to pass through fails in a safe way instead. A new field added to an underlying table tomorrow simply does not appear on the panel. It waits until someone purposely approves it. It does not appear by default until someone notices and removes it.

The third layer is where the design becomes truly special. After the allowlist has already run, a separate, independent function turns the response into its final JSON text. It then checks that finished text directly. It looks for specific banned field names. These include things like a question's content, an answer, a document's stored path, a taxpayer's income numbers, or a document ID. It also checks for text that looks like a Brazilian CPF or CNPJ number in any common format. If either check finds something, the entire response is refused right away. It gives a specific reason. The bad part is not quietly removed and the rest sent through. The code's own comment states the reason for that specific choice directly. A response that reaches this point and still has tax content means something was read from the wrong table. Or data was put together outside the planned path. The right thing to do when this happens is to fix the main problem. It is not to clean up the symptom and send the response anyway.

What makes this a truly enforced promise, rather than just an idea, is how it is built. Every single code path in this backend function that sends a response to the panel goes through one shared function. That shared function is the only place where the allowlist and the output-verification layer are used. There is no second, different way to create a response from this endpoint that skips either layer. This is confirmed by checking the current code. It is still true today.

What is actually built today

  • A structural layer where the database tables the internal panel's backend function queries have no column capable of storing tax content at all. This is separate from any check at the application level.

  • A positive, clearly stated allowlist of every field name the panel may show. It is applied at any level of nesting. A field not on the list simply does not appear, by default.

  • An independent output-verification function that checks the finished, converted JSON response. It looks for banned field names and for CPF/CNPJ-shaped patterns. It refuses to send the entire response if either check finds a match.

  • A single, shared response function that every code path in the backend goes through. It is confirmed to be the only place where the allowlist or the output verification runs. There is no other way around them.

  • A distinct field that clearly states "cost not yet estimable" as different from "zero cost." So, the panel can truly tell the difference. It does not treat an empty pricing table as proof nothing was spent.

  • Confirmed today by direct check: this three-layer structure is still complete and unchanged in the current code.

What changes operationally

Centriu's own operations team can manage the Income Tax module's licenses. They can investigate failures. They can review costs and quality. They do all this through this panel. A structural, an allowlist, and an output-verification guarantee — not just one filter — stands between that work and any person's actual tax content. A mistake that gets past any one layer still has two more chances to be caught. This happens before a response ever leaves the function.

  • Centriu's own operations team can manage the Income Tax module's licenses. They can investigate failures. They can review costs and quality. They do all this through this panel. A structural, an allowlist, and an output-verification guarantee — not just one filter — stands between that work and any person's actual tax content. A mistake that gets past any one layer still has two more chances to be caught. This happens before a response ever leaves the function.

A bad response, refused rather than cleaned (example situation, not a real client)

A future code change to this backend function accidentally adds a field from a table it was not supposed to touch. That field happens to hold a taxpayer's stored document ID. Before reaching the panel, the allowlist alone would already block a field with that name if it is not on the approved list. But if it somehow arrived under a name that sounds allowed, the output-verification layer's pattern check would still catch the CPF-shaped or document-shaped content in the finished response. It would refuse to send it. It would not quietly deliver a mostly-clean response with a sensitive part still inside.

A bad response, refused rather than cleaned (example situation, not a real client)

How to start

Frequently asked questions

Why does the internal panel need three separate layers instead of one good filter?

Because any single mechanism can eventually have a gap. This could be a new field, an unexpected code path, or an undiscovered bug. The three layers are made to be independent. So, a gap in one is still caught by another.

What happens if the allowlist misses a newly added sensitive field?

The output-verification layer checks the finished response on its own. It looks for banned field names and CPF/CNPJ-shaped patterns. If it finds a match, it refuses to send the entire response. This happens even if the allowlist did not catch it first.

Why refuse the whole response instead of just removing the bad part?

The code's own reason is that a response reaching that point with tax content means something was read from the wrong table earlier. It treats this as a bug to fix. It is not a symptom to quietly clean up.

How does the panel distinguish "no cost" from "cost not yet measured"?

A special field clearly shows if a real pricing table currently has entries. When it does not, the panel shows that cost is not yet estimable. It does not show a definite zero.

Is there any way to construct a response from this function that skips the allowlist or the output check?

No. It is confirmed directly in the current code that every response goes through one shared function. This is the only place where either layer is used.

What does Centriu Gauge cost?

It is sold by subscription with a published starting price. The exact current prices are on the central pricing page.

See how Centriu Gauge keeps its own internal panel away from tax content

Centriu's own internal operations team needs to run the Income Tax module as a product. They manage licenses, track cost, investigate failures, review quality, and publish versions. This work must not require or permit looking at anyone's actual tax content. The single backend function for that internal panel has three independent layers. This is because each layer alone will eventually fail. The first is a structural layer. The database tables this function can query have no column for storing tax content. This is true no matter what the application code does. The second is an allowlist layer. Only a positive, clear list of field names can pass through to the panel. So, a new column added to another table tomorrow is hidden by default. It is not shown by default. The third is an output-verification layer. It runs on the finished response, ready to send. It checks for banned field names and for CPF or CNPJ-shaped patterns. If anything matches, it refuses to send the response at all. It does not try to remove the bad part and send the rest. Every response from this function goes through the same single function on its way out. There is no other way around any of the three layers.