Governança e RLS: Como Controlar o Acesso a Dados Confidenciais na IA

Entenda como a segurança a nível de linha (Row-Level Security) garante que cada colaborador acesse na IA apenas os dados permitidos para sua função e área.

A governança de dados em inteligência artificial corporativa baseia-se na aplicação de segurança a nível de linha (Row-Level Security ou RLS) e controle de escopo por unidade organizacional. Essa arquitetura garante que, mesmo utilizando a mesma plataforma conversacional, cada colaborador acesse apenas os bancos de dados, tabelas e linhas de registro autorizados para o seu cargo e departamento. O bloqueio acontece diretamente na camada de consulta ao banco de dados, impedindo o vazamento de salários, margens restritas ou dados estratégicos entre áreas.

1. O Dilema da Segurança: Democratizar o Acesso sem Abrir Brechas de Vazamento

O maior freio para a adoção de inteligência artificial nas empresas não vem da falta de interesse das áreas de negócio, mas do veto legítimo das equipes de Segurança da Informação, Jurídico e Diretoria Financeira.

A preocupação dos executivos é concreta:

  • "Se conectarmos nosso banco de dados à IA para facilitar a vida dos gestores, um analista comercial vai conseguir perguntar quanto ganha um diretor?"
  • "O gerente de uma filial poderá ver a margem líquida e a carteira de clientes da filial vizinha?"
  • "Informações sensíveis de contratos estratégicos podem acabar expostas em uma conversa aberta de outro departamento?"

Se uma ferramenta de inteligência artificial oferece apenas uma chave binária de "tudo ou nada" (ou o banco está conectado para todo mundo ver tudo, ou ninguém vê nada), ela é inutilizável em uma empresa real. Democratizar dados exige governança cirúrgica.

2. Por Que "Pedir para a IA Guardar Segredo no Prompt" Não é Segurança

Um erro perigoso cometido por implementações caseiras de IA é tentar controlar o acesso aos dados usando apenas instruções de texto no prompt do sistema (por exemplo, escrever: "você não deve mostrar dados da diretoria para usuários comuns").

Em segurança da informação, regra de texto não é barreira de acesso. Se o banco de dados inteiro estiver aberto para a consulta da ferramenta, um usuário mal-intencionado ou uma pergunta formulada de maneira indireta pode contornar a instrução textual e extrair a informação restrita.

Abordagem Insegura (Filtro apenas no Prompt de Texto):

  1. Usuário pergunta
  2. IA consulta o Banco Inteiro sem filtro
  3. Tenta esconder no texto final
  4. Alto risco de vazamento (Prompt Injection)

Arquitetura Governada com RLS e Escopo de Unidade:

  1. Usuário autenticado pergunta
  2. Credencial trava o Escopo e injeta filtro RLS no SQL
  3. Banco só devolve as linhas permitidas
  4. Segurança aplicada na origem

A verdadeira segurança corporativa acontece antes de o dado sair do banco. Se o usuário não tem permissão para ver os registros da Região Norte, o banco de dados sequer retorna essas linhas para a camada da inteligência artificial.

3. As Três Camadas de Blindagem em uma Plataforma Governada

Para que a empresa inteira possa operar na mesma plataforma com tranquilidade total, o controle de acesso atua em três níveis simultâneos:

Camada de GovernançaO Que Ela ControlaExemplo Prático na Rotina da Empresa
1. Escopo por Unidade (Spaces)Quais modelos de dados, documentos e painéis cada departamento enxergaO espaço de Marketing enxerga apenas as bases de campanhas, eventos e CRM; não tem acesso aos modelos de Folha de Pagamento do RH
2. Segurança a Nível de Linha (RLS)Quais linhas específicas dentro de uma mesma tabela cada usuário pode lerDois gerentes regionais fazem a mesma pergunta no mesmo modelo de Vendas, mas cada um recebe apenas os números da sua própria regional
3. Alçada de Curadoria e PapéisQuem pode apenas consultar e quem pode aprovar regras, membros e fontes oficiaisAnalistas (membros) fazem análises e propõem aprendizados; apenas o líder (dono da unidade) promove decisões ou altera configurações

4. Governança Além do Banco: Painéis, Conhecimento e Memória Compartilhada

Em uma operação viva, os dados não ficam apenas nas tabelas SQL; eles viram gráficos, painéis, documentos e memórias da equipe. Por isso, a governança precisa acompanhar o dado em todo o seu ciclo de vida dentro da plataforma:

1. Separação Entre "Meu Espaço" e os Quadros da Unidade

Um colaborador pode criar rascunhos, testar painéis e fazer explorações no seu espaço pessoal sem expor nada para o restante da área. Quando um painel pessoal precisa ser aberto em uma conversa compartilhada da equipe, a plataforma exige uma confirmação explícita de aprovação antes de torná-lo visível para a unidade.

2. Regras de Confidencialidade Ativas por Departamento

Cada unidade pode estabelecer diretrizes estritas sobre o que pode e o que não pode ser exposto em materiais externos ou compartilhados (por exemplo: permitir análise agregada de custos de equipe, mas vedar qualquer exposição de salários individualizados ou nomes de clientes sob sigilo contratual).

3. Integração com Diretórios Corporativos (SSO e Grupos)

A gestão de quem entra e sai da empresa acompanha a infraestrutura oficial de identidade da organização (como login corporativo Google, Microsoft Azure AD e gerenciamento de grupos), garantindo que o desligamento de um colaborador revogue imediatamente todos os seus acessos.

5. Roteiro para Configurar Governança de IA sem Travar a Agilidade

  1. Mapeie os Domínios de Dados por Departamento: Agrupe os modelos semânticos conforme as áreas de negócio (Comercial, Marketing, Financeiro, Operações) e vincule cada modelo apenas às unidades que realmente precisam dele para trabalhar.
  2. Ative o RLS nas Tabelas Multirregionais ou Multiunidades: Onde houver necessidade de separar a visão por filial, carteira de representante ou centro de custo, configure a regra de linha vinculada à identidade do usuário logado.
  3. Defina os Donos de Cada Unidade (Owners): Nomeie os gestores responsáveis por cada espaço para que eles tenham a palavra final na janela de decisão sobre novas fontes, compromissos e regras oficiais da área.
  4. Mantenha Todas as Conexões em Modo Somente Leitura (Read-Only): Garanta no banco de dados que a credencial de consulta analítica tenha permissão exclusiva de seleção (SELECT), eliminando por completo qualquer possibilidade técnica de alteração ou exclusão acidental de registros na base original.

Como a Luria ajuda

Na Luria, as consultas rodam em um motor governado somente leitura, e o RLS fica no modelo semântico, vinculado ao grupo do usuário que executa a consulta. Cada Space define quais modelos, documentos e painéis a unidade enxerga, com os papéis membro, aprovador e dono, e as diretrizes de confidencialidade da unidade entram em toda resposta. No Portals Corporativo, cada card tem o seu "Quem pode acessar?" por grupo. O login é feito por SSO com Google Workspace ou Microsoft Entra ID (Azure AD), com leitura de grupos para controle de acesso (veja segurança e governança).

Leia também: Inteligência compartilhada: o repositório vivo · Onboarding imediato: dados no dia 1

Sua equipe de segurança tem perguntas sobre IA conectada aos dados? Agende uma conversa técnica com nosso time.

Perguntas frequentes

O que acontece se um usuário tentar enganar a IA para ver dados de outra área?

Como o controle de acesso e o RLS são aplicados diretamente na camada do servidor e do banco de dados a partir da identidade autenticada do usuário, nenhuma técnica de conversa (prompt injection) consegue acessar linhas ou tabelas fora do escopo autorizado. O dado simplesmente não existe para aquela sessão.

Se um diretor compartilhar um painel com um analista, o analista verá os dados restritos do diretor?

Não. Quando um painel está ligado a uma fonte de dados real (modelo semântico com RLS), cada abertura ou atualização refaz a consulta com as permissões de quem está visualizando: o analista só vê as linhas que a alçada dele permite, mesmo que o painel tenha sido criado pelo diretor. Além disso, a visibilidade de cada card nos espaços das unidades e no portal corporativo é segregada por grupos de acesso ("Quem pode acessar?") e por membros da unidade, e a plataforma informa a alçada de cada espaço (pessoal, da unidade ou corporativo) antes de qualquer compartilhamento.

Os dados consultados pela minha empresa são usados para treinar os modelos públicos dos provedores?

Não. As APIs corporativas dos principais provedores (Anthropic, OpenAI, Vertex AI, Bedrock e Azure OpenAI) têm como padrão não usar os dados trafegados nas consultas e análises para treinar modelos públicos. Vale confirmar essa política nos termos de cada provedor contratado pela sua empresa.

Governance and RLS: How to Control Access to Confidential Data in AI

Understand how row-level security ensures each employee accesses in AI only the data allowed for their role and department.

Data governance in enterprise AI is based on row-level security (RLS) and scope control by organizational unit. This architecture ensures that, even when using the same conversational platform, each employee accesses only the databases, tables and record rows authorized for their role and department. The block happens directly in the database query layer, preventing salaries, restricted margins or strategic data from leaking between areas.

1. The Security Dilemma: Democratizing Access Without Opening Leak Gaps

The biggest brake on AI adoption in companies does not come from a lack of interest from business areas, but from the legitimate veto of Information Security, Legal and Finance leadership.

Executives’ concerns are concrete:

  • "If we connect our database to AI to make managers’ lives easier, will a sales analyst be able to ask how much a director earns?"
  • "Will one branch manager be able to see the net margin and customer portfolio of the neighboring branch?"
  • "Could sensitive information from strategic contracts end up exposed in another department’s open conversation?"

If an AI tool offers only an "all or nothing" switch (either the database is connected for everyone to see everything, or no one sees anything), it is unusable in a real company. Democratizing data requires surgical governance.

2. Why "Asking the AI to Keep a Secret in the Prompt" Is Not Security

A dangerous mistake in homemade AI implementations is trying to control data access using only text instructions in the system prompt (for example, writing: "you must not show executive data to regular users").

In information security, a text rule is not an access barrier. If the entire database is open to the tool’s queries, a malicious user or an indirectly worded question can get around the text instruction and extract the restricted information.

Insecure Approach (Filter Only in the Text Prompt):

  1. User asks
  2. AI queries the Entire Database with no filter
  3. Tries to hide it in the final text
  4. High leak risk (Prompt Injection)

Governed Architecture with RLS and Unit Scope:

  1. Authenticated user asks
  2. The credential locks the Scope and injects the RLS filter into the SQL
  3. The database returns only the allowed rows
  4. Security enforced at the source

Real corporate security happens before the data leaves the database. If the user is not allowed to see North Region records, the database does not even return those rows to the AI layer.

3. The Three Layers of Protection in a Governed Platform

For the whole company to operate on the same platform with complete peace of mind, access control works on three levels at once:

Governance LayerWhat It ControlsPractical Example in the Company’s Routine
1. Scope by Unit (Spaces)Which data models, documents and dashboards each department seesThe Marketing space sees only the campaign, event and CRM data; it has no access to HR’s Payroll models
2. Row-Level Security (RLS)Which specific rows within the same table each user can readTwo regional managers ask the same question on the same Sales model, but each gets only their own region’s numbers
3. Curation Authority and RolesWho can only query and who can approve rules, members and official sourcesAnalysts (members) run analyses and propose learnings; only the leader (unit owner) promotes decisions or changes settings

4. Governance Beyond the Database: Dashboards, Knowledge and Shared Memory

In a living operation, data does not stay only in SQL tables; it becomes charts, dashboards, documents and team memories. That is why governance must follow the data through its entire lifecycle on the platform:

1. Separation Between "My Space" and the Unit’s Boards

An employee can create drafts, test dashboards and explore in their personal space without exposing anything to the rest of the area. When a personal dashboard needs to be opened in a shared team conversation, the platform requires explicit approval before making it visible to the unit.

2. Active Confidentiality Rules by Department

Each unit can set strict guidelines on what can and cannot be exposed in external or shared materials (for example: allowing aggregate analysis of team costs while forbidding any exposure of individual salaries or names of customers under contractual confidentiality).

3. Integration with Corporate Directories (SSO and Groups)

Managing who joins and leaves the company follows the organization’s official identity infrastructure (such as corporate Google login, Microsoft Azure AD and group management), ensuring that an employee’s departure immediately revokes all their access.

5. Roadmap for Setting Up AI Governance Without Slowing Down

  1. Map Data Domains by Department: Group semantic models by business area (Sales, Marketing, Finance, Operations) and link each model only to the units that actually need it to work.
  2. Enable RLS on Multi-Region or Multi-Unit Tables: Wherever the view needs to be separated by branch, sales rep portfolio or cost center, configure the row rule tied to the logged-in user’s identity.
  3. Define Each Unit’s Owners: Name the managers responsible for each space so they have the final say in the decision window on new sources, commitments and the area’s official rules.
  4. Keep All Connections Read-Only: Ensure in the database that the analytical query credential has SELECT permission only, completely eliminating any technical possibility of accidentally changing or deleting records in the original base.

How Luria helps

In Luria, queries run on a governed read-only engine, and RLS lives in the semantic model, tied to the group of the user running the query. Each Space defines which models, documents and dashboards the unit sees, with member, approver and owner roles, and the unit’s confidentiality guidelines go into every answer. In the Corporate Portals, each card has its own "Who can access?" setting by group. Login is through SSO with Google Workspace or Microsoft Entra ID (Azure AD), with group reading for access control (see security and governance).

Read also: Shared intelligence: the living repository · Instant onboarding: data on day 1

Does your security team have questions about AI connected to your data? Book a technical session with our team.

Frequently asked questions

What happens if a user tries to trick the AI into showing another area’s data?

Because access control and RLS are applied directly in the server and database layer based on the user’s authenticated identity, no conversation technique (prompt injection) can reach rows or tables outside the authorized scope. The data simply does not exist for that session.

If a director shares a dashboard with an analyst, will the analyst see the director’s restricted data?

No. When a dashboard is connected to a real data source (a semantic model with RLS), every time it is opened or refreshed the query runs again with the permissions of the person viewing it: the analyst only sees the rows their scope allows, even if the director created the dashboard. In addition, the visibility of each card in unit spaces and in the corporate portal is segregated by access groups ("Who can access?") and by unit membership, and the platform shows the scope of each space (personal, unit or corporate) before anything is shared.

Is the data my company queries used to train the providers’ public models?

No. The enterprise APIs of the main providers (Anthropic, OpenAI, Vertex AI, Bedrock and Azure OpenAI) by default do not use the data sent in queries and analyses to train public models. It is worth confirming this policy in the terms of each provider your company uses.

Gobernanza y RLS: Cómo Controlar el Acceso a Datos Confidenciales en la IA

Entienda cómo la seguridad a nivel de fila (Row-Level Security) garantiza que cada colaborador acceda en la IA solo a los datos permitidos para su función y área.

La gobernanza de datos en la inteligencia artificial corporativa se basa en la aplicación de seguridad a nivel de fila (Row-Level Security o RLS) y en el control de alcance por unidad organizacional. Esta arquitectura garantiza que, aun usando la misma plataforma conversacional, cada colaborador acceda solo a las bases de datos, tablas y filas de registro autorizadas para su cargo y área. El bloqueo ocurre directamente en la capa de consulta a la base de datos, impidiendo la fuga de salarios, márgenes restringidos o datos estratégicos entre áreas.

1. El Dilema de la Seguridad: Democratizar el Acceso sin Abrir Brechas de Fuga

El mayor freno a la adopción de inteligencia artificial en las empresas no viene de la falta de interés de las áreas de negocio, sino del veto legítimo de los equipos de Seguridad de la Información, Jurídico y Dirección Financiera.

La preocupación de los ejecutivos es concreta:

  • "Si conectamos nuestra base de datos a la IA para facilitar la vida de los gestores, ¿un analista comercial podrá preguntar cuánto gana un director?"
  • "¿El gerente de una sucursal podrá ver el margen neto y la cartera de clientes de la sucursal vecina?"
  • "¿Información sensible de contratos estratégicos podría terminar expuesta en una conversación abierta de otra área?"

Si una herramienta de inteligencia artificial ofrece solo un interruptor de "todo o nada" (o la base está conectada para que todos vean todo, o nadie ve nada), es inutilizable en una empresa real. Democratizar los datos exige una gobernanza quirúrgica.

2. Por Qué "Pedirle a la IA que Guarde un Secreto en el Prompt" No es Seguridad

Un error peligroso de las implementaciones caseras de IA es intentar controlar el acceso a los datos usando solo instrucciones de texto en el prompt del sistema (por ejemplo, escribir: "no debes mostrar datos de la dirección a usuarios comunes").

En seguridad de la información, una regla de texto no es una barrera de acceso. Si toda la base de datos está abierta a la consulta de la herramienta, un usuario malintencionado o una pregunta formulada de manera indirecta puede sortear la instrucción textual y extraer la información restringida.

Enfoque Inseguro (Filtro solo en el Prompt de Texto):

  1. El usuario pregunta
  2. La IA consulta toda la Base sin filtro
  3. Intenta ocultarlo en el texto final
  4. Alto riesgo de fuga (Prompt Injection)

Arquitectura Gobernada con RLS y Alcance de Unidad:

  1. El usuario autenticado pregunta
  2. La credencial fija el Alcance e inyecta el filtro RLS en el SQL
  3. La base solo devuelve las filas permitidas
  4. Seguridad aplicada en el origen

La verdadera seguridad corporativa ocurre antes de que el dato salga de la base. Si el usuario no tiene permiso para ver los registros de la Región Norte, la base de datos ni siquiera devuelve esas filas a la capa de inteligencia artificial.

3. Las Tres Capas de Blindaje en una Plataforma Gobernada

Para que toda la empresa pueda operar en la misma plataforma con total tranquilidad, el control de acceso actúa en tres niveles simultáneos:

Capa de GobernanzaQué ControlaEjemplo Práctico en la Rutina de la Empresa
1. Alcance por Unidad (Spaces)Qué modelos de datos, documentos y tableros ve cada áreaEl espacio de Marketing ve solo las bases de campañas, eventos y CRM; no tiene acceso a los modelos de Nómina de RR. HH.
2. Seguridad a Nivel de Fila (RLS)Qué filas específicas dentro de una misma tabla puede leer cada usuarioDos gerentes regionales hacen la misma pregunta en el mismo modelo de Ventas, pero cada uno recibe solo los números de su propia regional
3. Nivel de Curaduría y RolesQuién puede solo consultar y quién puede aprobar reglas, miembros y fuentes oficialesLos analistas (miembros) hacen análisis y proponen aprendizajes; solo el líder (dueño de la unidad) promueve decisiones o modifica configuraciones

4. Gobernanza Más Allá de la Base: Tableros, Conocimiento y Memoria Compartida

En una operación viva, los datos no quedan solo en las tablas SQL; se convierten en gráficos, tableros, documentos y memorias del equipo. Por eso, la gobernanza necesita acompañar al dato en todo su ciclo de vida dentro de la plataforma:

1. Separación Entre "Mi Espacio" y los Cuadros de la Unidad

Un colaborador puede crear borradores, probar tableros y hacer exploraciones en su espacio personal sin exponer nada al resto del área. Cuando un tablero personal necesita abrirse en una conversación compartida del equipo, la plataforma exige una confirmación explícita de aprobación antes de hacerlo visible para la unidad.

2. Reglas de Confidencialidad Activas por Área

Cada unidad puede establecer directrices estrictas sobre lo que puede y lo que no puede exponerse en materiales externos o compartidos (por ejemplo: permitir el análisis agregado de costos de equipo, pero prohibir cualquier exposición de salarios individuales o nombres de clientes bajo confidencialidad contractual).

3. Integración con Directorios Corporativos (SSO y Grupos)

La gestión de quién entra y sale de la empresa acompaña la infraestructura oficial de identidad de la organización (como el inicio de sesión corporativo de Google, Microsoft Azure AD y la gestión de grupos), garantizando que la desvinculación de un colaborador revoque de inmediato todos sus accesos.

5. Hoja de Ruta para Configurar la Gobernanza de IA sin Frenar la Agilidad

  1. Mapee los Dominios de Datos por Área: Agrupe los modelos semánticos según las áreas de negocio (Comercial, Marketing, Finanzas, Operaciones) y vincule cada modelo solo a las unidades que realmente lo necesitan para trabajar.
  2. Active el RLS en las Tablas Multirregionales o Multiunidad: Donde sea necesario separar la visión por sucursal, cartera de representante o centro de costo, configure la regla de fila vinculada a la identidad del usuario conectado.
  3. Defina los Dueños de Cada Unidad (Owners): Nombre a los gestores responsables de cada espacio para que tengan la última palabra en la ventana de decisión sobre nuevas fuentes, compromisos y reglas oficiales del área.
  4. Mantenga Todas las Conexiones en Modo Solo Lectura (Read-Only): Garantice en la base de datos que la credencial de consulta analítica tenga permiso exclusivo de selección (SELECT), eliminando por completo cualquier posibilidad técnica de modificación o eliminación accidental de registros en la base original.

Cómo ayuda Luria

En Luria, las consultas se ejecutan en un motor gobernado de solo lectura, y el RLS vive en el modelo semántico, vinculado al grupo del usuario que ejecuta la consulta. Cada Space define qué modelos, documentos y tableros ve la unidad, con los roles miembro, aprobador y dueño, y las directrices de confidencialidad de la unidad entran en cada respuesta. En el Portals Corporativo, cada tarjeta tiene su propio "¿Quién puede acceder?" por grupo. El inicio de sesión es por SSO con Google Workspace o Microsoft Entra ID (Azure AD), con lectura de grupos para el control de acceso (vea seguridad y gobernanza).

Lee también: Inteligencia compartida: el repositorio vivo · Onboarding inmediato: datos el día 1

¿Su equipo de seguridad tiene preguntas sobre IA conectada a los datos? Agende una conversación técnica con nuestro equipo.

Preguntas frecuentes

¿Qué ocurre si un usuario intenta engañar a la IA para ver datos de otra área?

Como el control de acceso y el RLS se aplican directamente en la capa del servidor y de la base de datos a partir de la identidad autenticada del usuario, ninguna técnica de conversación (prompt injection) logra acceder a filas o tablas fuera del alcance autorizado. El dato simplemente no existe para esa sesión.

Si un director comparte un tablero con un analista, ¿el analista verá los datos restringidos del director?

No. Cuando un tablero está conectado a una fuente de datos real (modelo semántico con RLS), cada apertura o actualización rehace la consulta con los permisos de quien lo está viendo: el analista solo ve las filas que su alcance permite, aunque el tablero lo haya creado el director. Además, la visibilidad de cada tarjeta en los espacios de las unidades y en el portal corporativo está segregada por grupos de acceso ("¿Quién puede acceder?") y por miembros de la unidad, y la plataforma informa el alcance de cada espacio (personal, de la unidad o corporativo) antes de cualquier uso compartido.

¿Los datos que consulta mi empresa se usan para entrenar los modelos públicos de los proveedores?

No. Las APIs corporativas de los principales proveedores (Anthropic, OpenAI, Vertex AI, Bedrock y Azure OpenAI) tienen como estándar no usar los datos enviados en las consultas y análisis para entrenar modelos públicos. Conviene confirmar esa política en los términos de cada proveedor contratado por su empresa.

Luria é o ecossistema brasileiro de agentes de IA enterprise, desenvolvido pela PX Data. Um agente treinado no contexto do negócio conecta os dados que já existem na operação, responde em linguagem natural e decide em segundos, com liberdade para escolher o modelo (Gemini, Claude, GPT) e governança para escalar entre todas as áreas. O ecossistema é composto por Luria One (inteligência e decisão), Luria Flow (automação de processos) e Luria Academy (adoção de IA).

A plataforma é parceira oficial Google Cloud, possui o selo Google Cloud Ready – BigQuery, e está disponível no Google Cloud Marketplace. A Luria foi reconhecida como uma das 100 Startups to Watch 2025 e é usada por empresas como Bradesco, BAT e Eurofarma.

Luria is the Brazilian enterprise AI agents ecosystem, developed by PX Data. A single agent trained on the company's business context connects the data that already exists in the operation, answers in natural language and decides in seconds, with freedom to choose the model (Gemini, Claude, GPT) and governance to scale across every area. The ecosystem consists of Luria One (intelligence and decision), Luria Flow (process automation) and Luria Academy (AI adoption).

The platform is an official Google Cloud Partner, holds the Google Cloud Ready – BigQuery designation, and is available on the Google Cloud Marketplace. Luria was recognized as one of the 100 Startups to Watch 2025 and is used by companies such as Bradesco, BAT and Eurofarma.

Luria es el ecosistema brasileño de agentes de IA enterprise, desarrollado por PX Data. Un agente entrenado en el contexto del negocio conecta los datos que ya existen en la operación, responde en lenguaje natural y decide en segundos, con libertad para elegir el modelo (Gemini, Claude, GPT) y gobernanza para escalar entre todas las áreas. El ecosistema está compuesto por Luria One (inteligencia y decisión), Luria Flow (automatización de procesos) y Luria Academy (adopción de IA).

La plataforma es partner oficial de Google Cloud, posee la designación Google Cloud Ready – BigQuery, y está disponible en el Google Cloud Marketplace. Luria fue reconocida como una de las 100 Startups to Watch 2025 y es utilizada por empresas como Bradesco, BAT y Eurofarma.

Como Contratar a Luria AI

A Luria está disponível no Google Cloud Marketplace para contratação direta com billing unificado, ou através de contato com a equipe de vendas para condições personalizadas.

How to Get Luria AI

Luria is available on the Google Cloud Marketplace for direct contracting with unified billing, or through the sales team for custom conditions.

Cómo Contratar Luria AI

Luria está disponible en el Google Cloud Marketplace para contratación directa con facturación unificada, o a través del equipo de ventas para condiciones personalizadas.