Gerar app com IA ficou fácil. Difícil é o acesso seguro a dados vivos, e a AWS acaba de mexer nisso

O primeiro app interno gerado por IA costuma brilhar na demo e dar problema uma semana depois. Alguém exportou uma planilha para o app ter dados. Na segunda-feira, os números já estão velhos. O app mostra os números de todas as regionais para qualquer pessoa com o link, porque a exportação não levou junto as permissões do sistema de origem. Ninguém agiu de má-fé. O app só pulou a parte difícil.

Fizemos esse argumento há poucos dias na análise do Copilot Managed Runtime: gerar apps ficou fácil, difícil é operá-los. Agora a AWS atacou um pedaço específico dessa parte difícil no Amazon Quick.

O que a AWS lançou

Os Quick Apps são aplicações criadas a partir de linguagem natural: o usuário descreve o que quer e um agente de IA escreve e publica um app web funcional. Num texto de 1º de outubro, a AWS explicou que os Quick Apps agora consultam datasets governados em tempo real, em vez de embutir uma cópia estática no momento da criação. Nas palavras da AWS, o app mostra dados atualizados agora e filtrados pelo que você tem permissão para ver.

As fontes suportadas incluem datasets do Quick Sight, nos modos SPICE (em memória) e Direct Query, fontes Direct Query de provedores suportados, conteúdo e documentos corporativos e conectores de ação como Jira, Slack e Google Drive.

O modelo de permissões é a parte que importa:

• Cada pessoa consulta com a própria identidade. O app não roda com o acesso de quem o criou.
• A segurança por linha e por coluna se aplica automaticamente, com as mesmas regras definidas no dataset.
• O consentimento é verificado no servidor a cada consulta, e quem vê precisa estar autenticado como usuário do Quick.

O texto da AWS não diz se o recurso está em preview ou em disponibilidade geral (GA), nem lista regiões específicas para ele.

Por que a cópia era o problema de verdade

1. Quem cria exporta uma cópia
2. O app embute a cópia
3. Todos veem as mesmas linhas velhas
4. Usuário faz login
5. A consulta roda como o usuário
6. Regras de linha e coluna valem, dado atual

• Cópia na criação: Quem cria exporta uma cópia · O app embute a cópia · Todos veem as mesmas linhas velhas
• Caminho governado na execução: Usuário faz login · A consulta roda como o usuário · Regras de linha e coluna valem, dado atual

Cópia sem controleAcesso governado

Uma cópia dentro do app falha de três jeitos ao mesmo tempo. Ela envelhece, e a decisão é tomada com número antigo. Ela perde as permissões, porque não sabe quem podia ver quais linhas. E é uma nova cópia de dados do negócio sem dono, sem regra de retenção e fora de qualquer inventário, que é exatamente o problema de custódia que descrevemos em nosso texto sobre custódia como primeira pergunta. Se a planilha tinha CPF de clientes, a empresa acabou de criar um tratamento de dados pessoais que ninguém mapeou para a LGPD.

Consultar o dataset governado na execução, com a identidade de quem vê, resolve as três coisas para os dados que moram nesse dataset. É uma melhora real de arquitetura, e é o padrão certo seja qual for o fornecedor: apps gerados por IA devem consumir produtos de dados governados, não cópias.

O que continua sendo responsabilidade sua

As regras do dataset precisam estar certas. O acesso ao vivo herda a segurança por linha e coluna; não a inventa. Se o dataset foi montado com acesso amplo porque só analistas usavam, um app em cima dele agora expõe essa amplitude a quem o app alcançar.

Ler e agir são riscos diferentes. Consultar um dataset como o usuário é leitura. Conectores de ação para Jira, Slack ou Google Drive escrevem em outros sistemas. Decida quais apps gerados podem usar ações e com a autoridade de quem.

A carga vai para a origem. O Direct Query manda consultas ao vivo para o banco de dados. Um app gerado que fizer sucesso pode virar uma carga não planejada num sistema de produção.

A região conta, e aqui o recorte brasileiro é concreto. A tabela de regiões do Amazon Quick mostra o serviço disponível em São Paulo, mas sem os recursos agênticos, que aparecem em regiões como N. Virginia, Oregon, Frankfurt, Irlanda e Londres. Na prática, uma empresa brasileira que queira usar recursos agênticos do Quick, o que inclui apps criados por agente, terá de operar numa região fora do país. Se os datasets têm dados pessoais, isso é transferência internacional nos termos da LGPD e da regulamentação da ANPD, com mecanismo e base legal próprios. A documentação também avisa que o roteamento da inferência não é configurável e que os logs do CloudTrail e do CloudWatch não registram em qual região ela aconteceu.

Alguém continua sendo dono do app. Dado ao vivo resolve a cópia velha, não a falta de dono. Apps gerados precisam de responsável, finalidade e data de fim.

O que fazer agora

1. Proíba cópias em apps gerados por IA onde houver dataset governado, e faça do caminho governado o modelo padrão.
2. Revise a segurança por linha e coluna dos datasets mais prováveis de serem usados por apps gerados antes de liberar o acesso ao vivo.
3. Separe apps de leitura de apps com ação e exija revisão para qualquer app gerado que use conectores de ação.
4. Leve a questão da região ao encarregado de dados antes de colocar datasets com dados pessoais num ambiente Quick fora do Brasil.
5. Registre os apps gerados com dono, fontes de dados e público, como já se faz com agentes.

Para fechar

A pergunta sobre apps corporativos gerados por IA nunca foi se o agente consegue escrever o código. É se o app chega aos dados do negócio pelo mesmo caminho governado de qualquer outro consumidor. A mudança da AWS torna esse o caminho mais fácil no Amazon Quick. As permissões que ele herda continuam precisando estar certas, e no Brasil a região onde tudo roda entra na mesma conta.