Orientações de Segurança em IA da Sandia Colocam Startups do Tri-Valley em Alerta

O Sandia National Laboratories reuniu quatro pesquisadores diante de startups do Tri-Valley com um alerta: a rápida adoção da IA está criando riscos que as revisões convencionais de software podem não detectar. O painel de 29 de julho levou os métodos de segurança em IA da Sandia para um contexto empresarial, no qual equipes pequenas muitas vezes implementam modelos antes de estabelecer programas formais de garantia.

O evento não apresentou um novo produto, padrão vinculante ou regulamentação. Sua importância veio do modelo operacional apresentado pela Sandia. As startups devem examinar dados, modelos, integrações e decisões humanas como um único sistema conectado e, então, testar esse sistema contra falhas e ataques realistas.

Essa posição cria um conflito claro entre velocidade de implementação e evidências de segurança. Startups competem lançando recursos cedo, aprendendo com usuários e mudando de direção rapidamente. A Sandia aborda a IA a partir de ambientes de alta consequência, nos quais uma falha inexplicada pode comprometer um sistema inteiro.

O painel também contestou uma suposição comum entre startups. Usar um modelo por meio de um fornecedor respeitável não transfere todos os riscos para esse fornecedor. A empresa que desenvolve a aplicação final ainda controla seu acesso a dados, camada de recuperação, ferramentas, permissões, experiência do usuário e procedimentos de resposta.

Isso torna a garantia de IA uma responsabilidade de produto, não um exercício final de conformidade. A questão imediata para fundadores é se suas equipes conseguem produzir evidências sobre o comportamento do sistema antes que clientes, reguladores ou atacantes as exijam.

Segurança em IA da Sandia Sai do Laboratório e Chega às Operações de Startups

O evento traduziu preocupações de segurança nacional em questões operacionais que empresas jovens já enfrentam.

A Daybreak Labs sediou o Lunch and Learn gratuito em Livermore, Califórnia, das 11h30 às 13h30. A incubadora sem fins lucrativos apoia startups de ciências da vida e deep tech na região do Tri-Valley.

O painel contou com Amanda Dodd, Gayle Thayer, Philip Kegelmeyer e Jonathan Crussell, da Sandia. Suas experiências abrangiam análise de segurança nacional, algoritmos seguros, análise de dados adversariais, segurança de software e fluxos de trabalho de IA agêntica.

Dodd, diretora de Computation and Analysis for National Security da Sandia, estruturou a discussão em torno de vulnerabilidades criadas pela adoção acelerada. Ela comparou a atual expansão da IA à ampla adoção da internet durante os anos 1990.

A comparação se concentrou na incerteza, não na nostalgia. A conectividade com a internet criou serviços valiosos, ao mesmo tempo que expôs sistemas a ataques e modos de falha que muitas organizações não haviam previsto. A IA agora acrescenta incertezas semelhantes dentro de sistemas que geram conteúdo, recomendam decisões e, em alguns casos, tomam ações.

Segundo o programa do evento, a discussão abordou velocidade versus segurança, inovação versus regulamentação e riscos envolvendo equipes humanas e de IA. Também examinou como as prioridades do governo e do setor privado se sobrepõem.

O subsequente relato do painel da Sandia descreveu três consequências empresariais das ameaças de IA: perda de propriedade intelectual, interrupção operacional e exposição regulatória. Esses resultados dão às fraquezas técnicas um significado financeiro e estratégico direto.

Thayer, gerente do departamento de Secure Algorithms da Sandia, explicou que a atenção à segurança está indo além do hardware e do software convencional. Pesquisadores examinam cada vez mais os próprios algoritmos e o comportamento que emerge de seu uso.

Essa mudança importa porque uma aplicação de IA pode operar conforme projetada e ainda assim produzir resultados inseguros. Um modelo pode divulgar contexto sensível, aceitar uma instrução maliciosa ou comportar-se de forma imprevisível fora de suas condições originais de teste.

A aplicação também pode falhar sem que alguém a ataque. Instruções ambíguas, dados desconhecidos, critérios de avaliação fracos ou um nível inadequado de autonomia podem gerar erros graves. A varredura convencional de vulnerabilidades não identificará todos esses problemas.

A abordagem da Sandia inclui red teaming, isto é, investigar ativamente um sistema em busca de fraquezas antes que um adversário as encontre. Os pesquisadores também avaliam parâmetros de confiabilidade, segurança e desempenho sob condições definidas.

Testar limites é diferente de apresentar uma única pontuação favorável de precisão. Uma avaliação útil pergunta onde o sistema deixa de se comportar de forma aceitável, quais entradas provocam essa mudança e se o monitoramento consegue detectá-la.

O painel, portanto, fez mais do que listar riscos de IA. Ele conectou a identificação de riscos a testes repetíveis, mitigação e design seguro. Essa sequência transforma um alerta abstrato em uma disciplina de engenharia.

Nada no relato público indica que a Sandia tenha certificado as startups participantes ou avaliado seus produtos. A sessão foi uma troca de abordagens e preocupações, não uma auditoria.

Essa distinção é importante. Um painel de duas horas não pode estabelecer se um sistema de IA específico é seguro. Pode, porém, mudar as perguntas que fundadores fazem antes de lançar um.

A Adoção Rápida de IA Deixa Startups com uma Lacuna de Garantia

Startups enfrentam pressão porque seus ciclos de lançamento são mais curtos do que o tempo necessário para compreender todos os comportamentos de um modelo.

Uma empresa jovem pode adicionar um modelo hospedado a um produto sem treinar esse modelo. Pode conectar documentos de clientes, registros internos ou ferramentas externas por meio de interfaces de programação de aplicações em um curto ciclo de desenvolvimento.

A aplicação resultante herda várias camadas de incerteza. Seu comportamento depende do modelo de base, das instruções de sistema, dos dados recuperados, das integrações de software, das permissões e da entrada do usuário.

Uma alteração em qualquer camada pode modificar o sistema. Um fornecedor de modelos pode atualizar seu comportamento, um índice de recuperação pode admitir novos documentos ou um cliente pode habilitar uma nova integração.

Essas mudanças criam o que as equipes frequentemente chamam de lacuna de garantia. O produto se desenvolve mais rápido do que as evidências da empresa sobre segurança, confiabilidade e comportamento aceitável.

A lacuna se torna mais grave quando um sistema de IA pode agir. Fluxos de trabalho agênticos são aplicações que permitem a um modelo planejar etapas e chamar ferramentas com intervenção humana limitada. Eles podem enviar mensagens, editar registros, executar código ou acionar processos empresariais.

Cada permissão adicional aumenta o impacto de uma resposta equivocada ou manipulada. Uma resposta fraca em uma janela de chat é inconveniente. A mesma resposta enviada a uma ferramenta de execução pode alterar dados ou expor informações.

A injeção de prompt ilustra a diferença. Um atacante insere instruções na entrada do usuário ou em conteúdo externo, esperando que o modelo as siga em vez das regras pretendidas pelo desenvolvedor.

A atual lista de riscos de LLM mantida pela OWASP identifica a injeção de prompt como uma grande vulnerabilidade de aplicações. Ela também aborda divulgação de informações sensíveis, fraquezas na cadeia de suprimentos, tratamento inadequado de saída e autonomia excessiva.

Esses riscos atravessam fronteiras organizacionais. Um fornecedor de modelos protege sua plataforma, enquanto um desenvolvedor de aplicações controla prompts, recuperação, ferramentas e regras de acesso. Um cliente, por sua vez, controla o comportamento dos usuários, os dados conectados e a configuração local.

Nenhum participante vê o sistema completo. Isso facilita a diluição de responsabilidades até que ocorra um incidente.

O painel da Sandia devolveu a responsabilidade à organização que implementa o sistema. O governo pode contribuir com pesquisa, estruturas e avaliações independentes. No entanto, as empresas ainda são responsáveis pelos riscos criados por seus produtos e escolhas operacionais.

Essa responsabilidade não exige que uma startup reproduza um laboratório nacional. Exige que a empresa defina o que significa comportamento seguro para seu próprio caso de uso.

Um assistente de pesquisa clínica e um gerador de textos de marketing não devem compartilhar critérios de aceitação idênticos. O primeiro lida com informações de consequências mais graves e exige evidências, controles de acesso e revisão mais rigorosos.

Startups também precisam separar qualidade do modelo de segurança do sistema. Um modelo pode ter bom desempenho em tarefas rotineiras, mas falhar diante de entradas adversariais. Pode responder com precisão e, ainda assim, revelar informações que um usuário não deveria receber.

O inverso também é possível. Uma aplicação pode impedir ataques comuns, mas ainda produzir recomendações pouco confiáveis. Segurança e utilidade se sobrepõem, mas uma não garante a outra.

Por isso, uma única pontuação de benchmark oferece pouca garantia. As equipes precisam de testes vinculados às tarefas pretendidas, ao uso indevido previsível, aos limites de acesso e às condições reais de implementação.

Elas também precisam de registros. Uma base de conhecimento pesquisável pode preservar versões de modelos, resultados de avaliação, incidentes e riscos aceitos entre equipes de engenharia e produto.

A documentação não é burocracia adicionada após o desenvolvimento. Ela permite que uma equipe identifique quando o comportamento mudou e se uma mitigação anterior continua funcionando.

A pressão é imediata e de longo prazo. Compradores empresariais já perguntam a fornecedores sobre tratamento de dados, fornecedores de modelos, controles de acesso e resposta a incidentes. Regras futuras podem tornar essas evidências mais formais.

Uma startup que não consegue responder a essas perguntas pode perder negócios antes mesmo de sofrer uma violação técnica. Nesse sentido, uma IA confiável torna-se parte da credibilidade do produto.

A Principal Escolha É Entre Velocidade e Evidências

A mensagem da Sandia não exige inovação mais lenta, mas exige evidências mais robustas antes que a IA receba maior autoridade.

Fundadores normalmente tratam a velocidade como uma exigência de sobrevivência. Lançar rapidamente gera feedback dos usuários, comprova a demanda e ajuda uma empresa pequena a competir com organizações de orçamentos maiores.

Equipes de segurança analisam o mesmo lançamento por outra perspectiva. Elas querem modelos de ameaça, testes, logs, limites de acesso e um plano de resposta antes que um sistema alcance dados sensíveis.

Ambas as posições têm preocupações válidas. Adiar cada recurso experimental até que ele cumpra padrões de alta consequência sobrecarregaria muitas startups. Implementar um sistema autônomo sem testes significativos exporia clientes a riscos que eles não conseguem enxergar.

A resposta prática é uma garantia proporcional. Um assistente de escrita de baixo impacto precisa de controles diferentes dos de um agente capaz de modificar registros financeiros, laboratoriais ou de produção.

A garantia proporcional começa com um contexto definido. A equipe documenta quem usará o sistema, quais dados ele pode acessar, quais ações pode realizar e quais falhas são inaceitáveis.

A empresa então mapeia ameaças plausíveis e modos comuns de falha. As ameaças incluem prompts maliciosos, dados contaminados, credenciais roubadas, dependências comprometidas e tentativas de extrair contexto privado.

Falhas comuns merecem a mesma atenção. Um modelo pode interpretar mal uma solicitação, inventar uma fonte, selecionar a ferramenta errada ou continuar operando depois que suas premissas se tornam inválidas.

Em seguida vem a medição. As equipes constroem conjuntos de avaliação a partir de tarefas realistas, casos extremos conhecidos e exemplos adversariais. Elas registram os resultados esperados antes de executar os testes.

Um teste útil tem uma condição de aprovação observável. “O modelo deve ser seguro” não é mensurável. “O assistente não deve retornar registros fora do espaço de trabalho do usuário autenticado” é específico o suficiente para ser testado.

A abordagem de red teaming da Sandia acrescenta a perspectiva de um atacante. Os testadores procuram rotas inesperadas através da aplicação completa, incluindo suas instruções, dados conectados, interfaces e ferramentas.

A comunidade mais ampla de laboratórios do Departamento de Energia descreveu trabalhos semelhantes. Um relatório sobre segurança de IA de múltiplos laboratórios afirma que benchmarks estáticos são insuficientes para prever comportamentos fora de condições familiares.

O relatório também identifica limitações de recursos. Avaliações abrangentes consomem capacidade computacional, trabalho especializado e tempo. Novos modelos chegam mais rápido do que os avaliadores conseguem analisar cada um de forma aprofundada.

Essa restrição é especialmente relevante para startups. Empresas pequenas não conseguem testar todas as entradas possíveis nem reproduzir as avaliações internas do provedor.

Ainda assim, elas podem testar a aplicação que controlam. Uma avaliação focada deve abranger os dados, as ferramentas, as funções de usuário e os fluxos de trabalho de maior impacto da empresa.

A mitigação vem depois dos testes. Uma equipe pode restringir permissões, isolar conteúdo não confiável, validar saídas, exigir aprovação humana ou limitar quais ferramentas o modelo pode chamar.

O controle mais forte frequentemente reduz as consequências de uma falha. Se um assistente apenas redige uma ação, um humano pode revisá-la. Se o assistente executa essa ação diretamente, a empresa precisa de autorização e monitoramento mais rigorosos.

A revisão humana não é automaticamente eficaz. Os revisores podem se tornar complacentes quando a maioria das saídas parece correta, especialmente sob pressão de tempo.

Por isso, as equipes devem identificar as decisões em que a revisão tem maior importância. Também devem apresentar contexto suficiente para que uma pessoa reconheça um resultado questionável.

O monitoramento fecha o ciclo. Os registros devem mostrar quais modelo, instruções, fontes de dados e ferramentas contribuíram para uma saída importante. Sem esse contexto, a investigação de incidentes vira adivinhação.

Nenhuma dessas etapas cria uma garantia permanente. O comportamento do modelo, o código da aplicação, os dados e os atacantes mudam. Os testes precisam continuar durante toda a vida do sistema.

É nesse ponto que o conflito entre velocidade e evidência se torna administrável. Uma startup pode avançar rapidamente em um ambiente restrito e, depois, ampliar sua autoridade à medida que as evidências melhoram.

Ela pode começar com usuários internos, dados sintéticos e ferramentas somente de leitura. Estágios posteriores podem adicionar dados de clientes ou ações limitadas depois que o sistema atingir limites explícitos.

Esse caminho trata a segurança como parte do desenvolvimento do produto. Ele evita a falsa escolha entre bloquear todos os experimentos e lançar todas as capacidades sem limites.

Os Frameworks Ajudam, mas Não Certificam um Produto

Os frameworks existentes organizam o trabalho de risco em IA, mas não conseguem determinar se a aplicação de uma startup é segura o bastante.

O NIST AI Risk Management Framework oferece às organizações quatro funções conectadas: governar, mapear, medir e gerenciar. A governança se aplica às demais funções, em vez de aparecer apenas no fim.

O framework é voluntário e projetado para uso amplo. Seu framework de risco em IA ajuda organizações a incorporar confiabilidade ao design, desenvolvimento, implantação, uso e avaliação de IA.

Para uma startup, “governar” significa atribuir autoridade de decisão e documentar a tolerância a riscos. Alguém precisa decidir quais casos de uso são permitidos e quais evidências sustentam o lançamento.

“Mapear” significa entender o contexto. As equipes identificam usuários, partes afetadas, dados, dependências, benefícios esperados e possíveis danos.

“Medir” abrange testes e análises. Inclui avaliação de desempenho, testes de segurança, avaliação de incertezas e monitoramento segundo critérios definidos.

“Gerenciar” transforma descobertas em prioridades e ações. Uma empresa aceita, reduz, transfere ou evita riscos com base na gravidade e nos controles disponíveis.

O NIST também publicou um perfil de IA generativa em julho de 2024. O perfil adapta o framework mais amplo aos riscos que sistemas generativos introduzem ou intensificam.

Esses recursos fornecem vocabulário e estrutura. Eles não inspecionam um produto, garantem conformidade nem certificam o comportamento de um modelo.

A posição da Sandia parece mais tecnicamente exigente do que simplesmente adotar a linguagem de um framework. Seus pesquisadores enfatizaram red teaming, benchmarking, design seguro e compreensão dos limites de desempenho.

Essa ênfase importa porque documentos de governança podem se desconectar do software. Um registro de riscos pode indicar que a injeção de prompts foi tratada, enquanto o sistema de recuperação implantado ainda repassa instruções não confiáveis a um modelo.

As evidências devem conectar cada risco identificado a um controle e a um teste. A empresa também deve saber quais riscos permanecem após a mitigação.

Uma avaliação independente pode fortalecer esse processo. A Sandia descreveu centros de pesquisa e desenvolvimento financiados pelo governo federal como fontes de análise técnica imparcial.

No entanto, o relatório público do painel não anunciou um serviço geral de certificação da Sandia para startups. Ele expressou interesse em identificar onde a indústria pode atender às necessidades de garantia e onde os laboratórios nacionais podem suprir lacunas.

Isso é um convite à colaboração, não prova de um caminho concluído. Acesso, escopo, tratamento de propriedade intelectual e arranjos de contratação determinarão se startups individuais poderão participar.

A Sandia já opera programas que conectam laboratórios, universidades e empresas menores. Seu programa RAIICE busca fornecer conjuntos de dados abertos e planejamento técnico para trabalhos de IA e machine learning relacionados à energia resiliente.

O RAIICE demonstra um modelo de parceria, mas não deve ser confundido com o painel de segurança de julho. O painel não anunciou que os participantes haviam entrado nesse programa.

Essa distinção revela o ângulo cético da mensagem da Sandia. A expertise técnica existe, e os fundadores claramente precisam dela. O que permanece incerto é até que ponto essa expertise pode alcançar equipes comerciais.

Os laboratórios nacionais trabalham sob missões específicas, regras de contratação e limitações de recursos. Startups operam em cronogramas comprimidos e podem precisar de respostas em poucos dias.

Um modelo de colaboração precisa conectar esses ritmos. Ele deve transformar métodos de pesquisa em testes que equipes pequenas possam executar, repetir e explicar aos clientes.

A regulamentação cria outra incerteza. Os participantes do painel teriam defendido regras claras que permitam à indústria assumir os riscos de IA de forma responsável, mas o evento não produziu nenhuma norma legal proposta.

As regras podem esclarecer expectativas, mas também podem se tornar obsoletas à medida que modelos e aplicações mudam. Exigências prescritivas podem recompensar a conclusão de checklists sem melhorar o comportamento real.

Regras focadas em resultados criam um problema diferente. Elas podem dizer às empresas qual resultado atingir sem oferecer formas acessíveis de demonstrá-lo.

O melhor sinal no curto prazo será evidência prática. Métodos públicos de teste, ferramentas reutilizáveis de avaliação, conjuntos de dados acessíveis e colaborações documentadas com startups mostrariam que a visão de parceria está se tornando operacional.

Até lá, as empresas não devem afirmar que a adoção de frameworks comprova segurança. Elas devem descrever os controles que usam, os testes que realizaram e as limitações que ainda observam.

O Que Fundadores e Compradores Devem Observar em Seguida

O próximo teste é saber se a linguagem de risco da Sandia produzirá práticas repetíveis, parcerias confiáveis e expectativas de mercado mais claras.

O primeiro sinal é uma via concreta de colaboração para pequenas empresas. A Sandia afirmou que deseja identificar onde a indústria pode atender às necessidades de garantia e onde os laboratórios nacionais podem preencher lacunas.

Uma via útil definiria projetos elegíveis, expertise disponível, requisitos de tratamento de dados, entregáveis esperados e prazos de engajamento. Estudos de caso públicos tornariam o modelo mais fácil de avaliar.

Se esses detalhes surgirem, eles fortalecerão a alegação central do painel. Mostrariam que os métodos dos laboratórios nacionais podem ir além da discussão e apoiar o desenvolvimento comercial.

Se nenhuma via aparecer, o evento continuará sendo uma iniciativa valiosa de aproximação, mas oferecerá ajuda operacional limitada. As startups ainda precisarão montar seus próprios programas de teste ou contratar especialistas externos.

O segundo sinal é a validação técnica vinculada a aplicações reais. Os fundadores devem observar avaliações publicadas que cubram injeção de prompts, vazamento de dados, manipulação de modelos, uso inseguro de ferramentas e comportamento fora das condições normais de teste.

O trabalho mais útil relatará condições de falha e riscos residuais, não apenas resultados favoráveis. Ele deve explicar o que mudou após os testes e se a mitigação resistiu a outro ciclo de ataque.

Essas evidências fortaleceriam o argumento de que uma IA confiável cria vantagem competitiva. Os compradores podem comparar fornecedores com mais confiança quando as empresas apresentam resultados repetíveis.

A falta de evidências enfraqueceria esse argumento. A linguagem de segurança, por si só, não diferencia um produto de outro, especialmente quando todos os fornecedores fazem promessas semelhantes.

O terceiro sinal é o movimento de frameworks amplos para expectativas mais claras de clientes e reguladores. O NIST está revisando o AI RMF 1.0 e desenvolvendo perfis adicionais para cibersegurança e infraestrutura crítica.

Os fundadores devem acompanhar se questionários empresariais, requisitos de compras, análises de seguros e regras setoriais começam a pedir evidências semelhantes. A convergência reduziria a incerteza sobre quais controles merecem investimento inicial.

A fragmentação criaria uma carga maior. Uma startup poderia enfrentar formatos de avaliação diferentes de cada cliente, regulador e parceiro.

Os compradores têm um papel na definição desse resultado. Eles devem perguntar aos fornecedores quais modelos e fontes de dados sustentam um fluxo de trabalho, quais ações o sistema pode realizar e como o fornecedor testa os limites de acesso.

Também devem perguntar o que acontece após uma atualização do modelo. Uma avaliação anterior oferece proteção limitada se um provedor muda o comportamento ou se a aplicação ganha novas ferramentas.

Os desenvolvedores devem tratar cada permissão adicionada como uma nova decisão de segurança. Conectar um assistente a e-mail, código-fonte, registros de clientes ou dados de laboratório altera as consequências de uma falha.

Os trabalhadores do conhecimento também devem entender esses limites. Eles precisam de sinais claros sobre quais informações podem entrar em um sistema de IA e quais saídas exigem revisão independente.

O painel da Sandia não resolveu essas questões. Ele tornou mais difícil para as startups adiá-las.

A lição mais duradoura é que a segurança em IA abrange todo o sistema operacional em torno de um modelo. Dados, instruções, software, permissões, usuários e monitoramento influenciam o resultado.

Essa lição também esclarece o que os fundadores devem fazer agora. Definir o sistema, classificar suas falhas de maior impacto, testar essas falhas, reduzir permissões e reter evidências.

Depois, devem perguntar se cada nova capacidade merece a autoridade que recebe. Uma demonstração convincente não é um caso de garantia, e a reputação de um provedor não substitui testes da aplicação.

A orientação de segurança em IA da Sandia terá mais importância se as empresas transformarem essa disciplina em trabalho rotineiro de produto. Os fundadores devem começar selecionando um fluxo de trabalho consequente e documentando seus riscos, controles, testes e limites não resolvidos.