Entende o contexto
Lê a operação, o cliente e o histórico antes de propor qualquer coisa.
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
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 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.
As áreas abaixo são partes da mesma operação, não produtos separados. Elas compartilham conta, permissões e histórico.
A inteligência artificial da Centriu participa da operação: entende contexto, prepara trabalho, executa rotinas e pede aprovação quando importa.
Lê a operação, o cliente e o histórico antes de propor qualquer coisa.
Redige, organiza, calcula e deixa pronto para revisão humana.
Roda o que é repetitivo dentro dos limites definidos pela empresa.
Cruza áreas, identifica prioridade e mostra o motivo da recomendação.
O que é sensível passa por uma pessoa antes de valer. Sem exceção silenciosa.
Registra o que aconteceu e usa o resultado para melhorar a próxima decisão.
Uma plataforma, várias frentes de trabalho. Tudo no mesmo contexto, com a IA participando do que dá para acelerar.
CRM, pipeline, oportunidades, propostas, follow-up e automações.
WhatsApp, Instagram, Messenger, chat do site e e-mail no mesmo contexto.
Tarefas, responsáveis, prazos, aprovações, agenda e capacidade.
Contas, cobranças, caixa, fiscal, margem, IR, orçamento e inteligência econômica.
Planejar, produzir, aprovar, publicar e medir conteúdo e campanhas.
Painéis, alertas, previsões, recomendações e leitura executiva.
Rotinas executadas continuamente pela IA com controle e aprovação.
Diagnóstico, estratégia, transformação, acompanhamento e especialistas.
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 funcionandoA Centriu combina tecnologia, inteligência, método e acompanhamento. A consultoria diagnostica, desenha, implanta e acompanha — com evidências, não com apresentação.
Diagnóstico e imersão na operação
Estratégia e prioridades
Roadmap de transformação
Desenho da arquitetura operacional
Implantação conduzida
Acompanhamento com evidências
Benchmarking e leitura de mercado
Especialistas, rede e inteligência coletiva
Uma conversa para entender onde a sua operação perde tempo, dinheiro ou capacidade — e o que a Centriu faria primeiro.
problema
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.

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.
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.
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.
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 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.

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.
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.
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.
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.
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.
It is sold by subscription with a published starting price. The exact current prices are on the central pricing page.
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.