Início · Segurança
O vazamento que ninguém vê é entre pessoas da mesma empresa.
Um representante que enxerga a carteira do colega não gera erro, não gera alerta e não gera log. A resposta chega bonita, com um número a mais. É esse risco que desenha a arquitetura da AYIA.
O recorte por usuário
Quatro camadas, e só a última é garantia
Instruir o modelo a filtrar funciona quase sempre. "Quase sempre" é exatamente o que não serve para permissão de acesso. Por isso as três primeiras camadas buscam a resposta certa, e a quarta impede a errada.
Camada 1
O modelo já recebe o recorte
A instrução de geração carrega os valores que aquele usuário alcança — representante, região, marca — e as colunas restritas são removidas do dicionário antes do envio. O que ele não pode ler, o modelo não vê.
Camada 2
Correção não apaga o filtro
Quando uma consulta precisa ser corrigida, o filtro do usuário viaja como cláusula intocável. Foi uma correção descuidada que originou este cuidado: a reescrita descartou o filtro e executou sem ele.
Camada 3
Exemplo aprendido entra neutralizado
A AYIA aprende com consultas já validadas. Esses exemplos entram sempre com o filtro removido, para nunca ensinarem o recorte de uma pessoa a outra.
Camada 4 · garantia
Portão determinístico
Existe uma única porta de saída para o banco, e nela um verificador em código — não um modelo — confere o recorte da consulta final, depois de qualquer reescrita. Não bateu, não executa.
Falha fechada. Se a leitura das permissões falhar, a AYIA bloqueia em vez de liberar. É o oposto do comportamento intuitivo — e é o único aceitável, porque "não consegui ler a restrição" jamais pode significar "então mostre tudo".
Isolamento entre clientes
Um banco por empresa. Não um filtro.
Cada cliente tem o seu próprio banco de dados analítico e o seu próprio dicionário. Não existe uma tabela compartilhada onde a separação dependa de alguém lembrar de aplicar a condição certa.
- Banco de dados próprio por cliente, com credenciais próprias.
- Dicionário do negócio versionado e escopado por cliente, nunca copiado de outro.
- Serviços e portas separados por cliente, com implantação independente.
- Cadastro de acesso centralizado e auditável, separado do dado de negócio.
Autenticação
Acesso por credencial da própria empresa, com sessão assinada e expiração. O papel do usuário vem da fonte oficial, não de uma cópia local que envelhece.
Identidade em todos os canais
No WhatsApp, o telefone precisa estar cadastrado para a pessoa existir. Número desconhecido é recusado com educação e sem dado — nunca cai em um usuário genérico.
Troca de usuário controlada
Quando um gestor precisa ver o sistema como um membro do time, isso acontece por um caminho explícito, restrito a perfis autorizados e registrado.
Um caminho só até o bancochave
Chat, painel, drill-down, relatório agendado e agente passam pela mesma porta de execução. Caminho novo que não passe por ela não entra no produto.
O que sai do seu ambiente
O modelo vê o mínimo necessário
Para escrever a consulta, o modelo precisa do dicionário de tabelas — não dos seus dados. Para interpretar o resultado, ele precisa das linhas retornadas. A diferença entre essas duas fases é o que define o que pode ser protegido.
Nomes viram códigos
No modo de anonimização, nomes de clientes e vendedores são trocados por identificadores estáveis antes do envio. Os números vão inteiros — a análise não perde nada.
Coluna proibida não é enviada
Coluna restrita ao usuário é removida do dicionário antes de qualquer chamada. Ela não é filtrada depois: ela nunca chega a existir naquela conversa.
Sem treinamento com o seu dado
A AYIA não treina modelo com a sua base. O aprendizado do produto é sobre consultas validadas, guardado no seu próprio ambiente.
Degradação segura
Se a troca de nomes falhar em algum ponto, o pior caso é o usuário ver um código em vez do nome. Nunca o contrário.
Auditoria
Toda pergunta deixa rastro
Sem registro não há revisão, e sem revisão o sistema não melhora. A AYIA guarda o caminho inteiro de cada pergunta — inclusive o que costuma se perder.
Do incômodo à correção
O registro alimenta uma rotina de curadoria: alguém lê as perguntas que deram trabalho, decide o ajuste, aplica e só então o sistema avisa quem penou que aquilo foi resolvido — citando a pergunta que a própria pessoa fez.
O passo humano é intencional. Anunciar melhoria que não foi verificada é pior que ficar quieto.
Registro não é burocracia. É a única forma de responder, seis meses depois, de onde veio aquele número. Princípio de arquitetura da AYIA
Proteção de dados
LGPD tratada como contrato, não como selo
A AYIA opera dados pessoais em nome do cliente: nome de contato, telefone, identificação de representante e de comprador. Isso é dito de forma explícita no contrato, com papéis definidos, e não escondido em uma página de conformidade.
- Papéis definidos. O cliente é o controlador do dado; a AYIA opera segundo instrução dele.
- Limitação de propósito por cláusula. O dado é usado para operar o serviço contratado, e o contrato declara isso.
- Inventário do que é tratado. Quais campos, em quais tabelas, com qual finalidade — mapeado, não presumido.
- Minimização na prática. Anonimização antes do envio ao modelo e remoção de colunas restritas por usuário.
- Anexo contratual disponível para a área jurídica antes da assinatura, sem cobrança e sem enrolação.
O que perguntamos de volta
Toda avaliação de fornecedor tem um questionário. O nosso costuma devolver três perguntas ao cliente, porque as respostas mudam a implantação:
- Quem, na sua empresa, decide o que cada perfil pode enxergar?
- Existe hoje algum relatório que circula com dado que não deveria circular?
- Por quanto tempo o histórico precisa ficar disponível?
Traga o seu time de TI para a conversa
A demonstração técnica cobre arquitetura, isolamento, permissões e auditoria. Perguntas difíceis são bem-vindas — são elas que desenharam o produto.