Aplicativos de IA em produ\u00e7\u00e3o precisam de mais do que um bom prompt. Eles precisam de uma camada de controle que possa inspecionar o que entra no modelo, inspecionar o que retorna e tomar uma decis\u00e3o clara antes que a resposta chegue a um usu\u00e1rio ou sistema subsequente.<\/p>\n\n\n\n
Essa \u00e9 a ideia por tr\u00e1s das diretrizes de gateway de IA.<\/p>\n\n\n\n
A arquitetura exata varia de acordo com o produto. Algumas equipes colocam verifica\u00e7\u00f5es no backend do aplicativo. Algumas usam um gateway ou proxy. Outras combinam configura\u00e7\u00f5es de seguran\u00e7a no n\u00edvel do modelo com valida\u00e7\u00e3o personalizada. O ponto importante \u00e9 que a seguran\u00e7a n\u00e3o deve depender de cada equipe de recursos lembrar de integrar a mesma l\u00f3gica em cada endpoint.<\/p>\n\n\n\n
Para os Desenvolvedores, as diretrizes fazem parte da responsabilidade do produto. O ShareAI pode ajud\u00e1-lo a direcionar o uso do modelo e monetizar o tr\u00e1fego de IA, mas seu aplicativo ainda \u00e9 respons\u00e1vel por pol\u00edticas, permiss\u00f5es, registros, experi\u00eancia do cliente e revis\u00e3o humana.<\/p>\n\n\n\n
Um aplicativo de IA geralmente come\u00e7a simples. Um endpoint chama um modelo. Em seguida, o uso se expande: mais recursos, mais clientes, mais provedores de modelos, mais ferramentas internas, mais entradas geradas por usu\u00e1rios e mais lugares onde uma resposta gerada pode desencadear uma a\u00e7\u00e3o.<\/p>\n\n\n\n
Nesse ponto, a l\u00f3gica de seguran\u00e7a por recurso torna-se dif\u00edcil de confiar. Uma vers\u00e3o do aplicativo pode bloquear inje\u00e7\u00e3o de prompt. Outra pode apenas verificar toxicidade. Uma terceira pode pular a valida\u00e7\u00e3o de sa\u00edda porque a equipe estava correndo para o lan\u00e7amento.<\/p>\n\n\n\n
As diretrizes no n\u00edvel do gateway resolvem o problema de consist\u00eancia ao colocar a valida\u00e7\u00e3o pr\u00f3xima ao tr\u00e1fego do modelo. O aplicativo pode enviar uma solicita\u00e7\u00e3o por meio de uma camada compartilhada que avalia o prompt, a resposta do modelo ou ambos. A camada retorna um veredicto como permitir, bloquear, redigir, revisar ou tentar novamente.<\/p>\n\n\n\n
Isso n\u00e3o elimina a necessidade de julgamento do produto. Cria um \u00fanico lugar para aplic\u00e1-lo.<\/p>\n\n\n\n
Boas diretrizes devem responder a quatro perguntas:<\/p>\n\n\n\n
A valida\u00e7\u00e3o de entrada detecta riscos antes que eles cheguem ao modelo.<\/p>\n\n\n\n
A primeira categoria \u00e9 a inje\u00e7\u00e3o de prompt. Um usu\u00e1rio, documento, p\u00e1gina da web ou resultado de ferramenta pode conter instru\u00e7\u00f5es projetadas para substituir o prompt do sistema, vazar contexto oculto ou for\u00e7ar o modelo a chamar uma ferramenta que n\u00e3o deveria usar. O OWASP Top 10 para Aplica\u00e7\u00f5es LLM<\/a> trata a inje\u00e7\u00e3o de prompt e a ag\u00eancia excessiva como riscos centrais de aplica\u00e7\u00f5es LLM por um motivo: o modelo pode estar seguindo instru\u00e7\u00f5es, mas o produto ainda \u00e9 respons\u00e1vel pelo resultado.<\/p>\n\n\n\n A segunda categoria \u00e9 a adequa\u00e7\u00e3o \u00e0 pol\u00edtica. Se seu aplicativo n\u00e3o suporta conte\u00fado relacionado a sa\u00fade, jur\u00eddico, financeiro, adulto, abusivo ou autoles\u00e3o, valide isso antes de gastar tokens do modelo ou criar uma resposta voltada para o cliente.<\/p>\n\n\n\n A terceira categoria s\u00e3o dados sens\u00edveis. Alguns prompts podem conter segredos, credenciais, dados pessoais ou conte\u00fado propriet\u00e1rio que devem ser bloqueados, mascarados ou encaminhados por um fluxo de trabalho mais rigoroso.<\/p>\n\n\n\n A quarta categoria \u00e9 a permiss\u00e3o de ferramentas. Se seu aplicativo conecta modelos a ferramentas por meio de padr\u00f5es como o Protocolo de Contexto de Modelo<\/a>, a valida\u00e7\u00e3o deve considerar o que o modelo tem permiss\u00e3o para acessar. Ler um arquivo, consultar um banco de dados, enviar um e-mail e excluir um registro n\u00e3o devem compartilhar o mesmo n\u00edvel de confian\u00e7a.<\/p>\n\n\n\n A valida\u00e7\u00e3o de sa\u00edda detecta problemas ap\u00f3s a gera\u00e7\u00e3o, mas antes da exposi\u00e7\u00e3o.<\/p>\n\n\n\n Comece com verifica\u00e7\u00f5es diretas de seguran\u00e7a: toxicidade, ass\u00e9dio, instru\u00e7\u00f5es inseguras, informa\u00e7\u00f5es sens\u00edveis e viola\u00e7\u00f5es de pol\u00edticas. O modelo pode produzir algo que seu produto n\u00e3o deve exibir, mesmo que o prompt original pare\u00e7a inofensivo.<\/p>\n\n\n\n Em seguida, valide o embasamento. Se seu aplicativo fornece documentos de refer\u00eancia, trechos de recupera\u00e7\u00e3o, linhas de banco de dados ou registros de clientes, a resposta deve ser verificada em rela\u00e7\u00e3o a esse contexto. Uma resposta fluente sem suporte pode ser mais prejudicial do que uma falha \u00f3bvia porque os usu\u00e1rios t\u00eam mais probabilidade de confiar nela.<\/p>\n\n\n\n Depois, valide a estrutura. Se a sa\u00edda deve ser JSON, um macro de suporte, uma cl\u00e1usula contratual, uma atualiza\u00e7\u00e3o de banco de dados ou um comando de ferramenta, verifique o esquema e os campos permitidos. N\u00e3o permita que um modelo escreva texto arbitr\u00e1rio em um lugar que espera dados restritos.<\/p>\n\n\n\n Por fim, valide a prontid\u00e3o para a\u00e7\u00e3o. Um rascunho de e-mail pode ser mostrado a um usu\u00e1rio para revis\u00e3o. Uma aprova\u00e7\u00e3o de reembolso, altera\u00e7\u00e3o de conta, mesclagem de c\u00f3digo ou notifica\u00e7\u00e3o ao cliente pode precisar de uma aprova\u00e7\u00e3o expl\u00edcita de um humano.<\/p>\n\n\n\n O objetivo n\u00e3o \u00e9 tornar cada resposta perfeita. \u00c9 evitar que falhas previs\u00edveis cheguem a lugares onde sejam custosas.<\/p>\n\n\n\n Um guardrail s\u00f3 \u00e9 \u00fatil se o produto souber o que fazer com o veredicto.<\/p>\n\n\n\n Para quest\u00f5es de baixo risco, o aplicativo pode pedir ao usu\u00e1rio para revisar o prompt. Para sa\u00eddas n\u00e3o suportadas, o aplicativo pode responder com uma alternativa segura e explicar que n\u00e3o conseguiu verificar o resultado. Para a\u00e7\u00f5es de alto risco, o aplicativo pode enviar a execu\u00e7\u00e3o para um revisor humano.<\/p>\n\n\n\n A decis\u00e3o mais dif\u00edcil \u00e9 como lidar com falhas no sistema de guardrail. Se a valida\u00e7\u00e3o n\u00e3o estiver dispon\u00edvel, o aplicativo deve falhar aberto e continuar, ou falhar fechado e bloquear a solicita\u00e7\u00e3o?<\/p>\n\n\n\n N\u00e3o h\u00e1 uma resposta universal.<\/p>\n\n\n\n Falhar aberto pode ser razo\u00e1vel para recursos de reda\u00e7\u00e3o de baixo risco, onde a disponibilidade \u00e9 importante e a sa\u00edda ainda requer revis\u00e3o do usu\u00e1rio. Falhar fechado \u00e9 mais seguro para fluxos de trabalho que envolvem conselhos regulamentados, a\u00e7\u00f5es financeiras, altera\u00e7\u00f5es de conta, dados privados ou execu\u00e7\u00e3o de ferramentas externas.<\/p>\n\n\n\n Tome essa decis\u00e3o por fluxo de trabalho, n\u00e3o globalmente. Um produto pode ser permissivo para brainstorming e rigoroso para a\u00e7\u00f5es que afetam clientes, dinheiro, dados ou seguran\u00e7a.<\/p>\n\n\n\n O ShareAI ajuda os Builders a conectar o uso de IA a um marketplace e camada de API. Os Builders podem direcionar a infer\u00eancia atrav\u00e9s do ShareAI, escolher modelos do marketplace de modelo transparente<\/a>, e definir uma margem quando seu pr\u00f3prio aplicativo gera uso de IA.<\/p>\n\n\n\n Isso n\u00e3o torna o ShareAI o propriet\u00e1rio do modelo de seguran\u00e7a do seu produto.<\/p>\n\n\n\n O Builder ainda \u00e9 respons\u00e1vel por:<\/p>\n\n\n\n Essa distin\u00e7\u00e3o \u00e9 importante. O ShareAI pode apoiar a economia do seu produto de IA, mas os limites fazem parte do contrato do aplicativo que voc\u00ea estabelece com os clientes.<\/p>\n\n\n\n Se voc\u00ea estiver implementando um fluxo de trabalho do Builder, comece com o documenta\u00e7\u00e3o do ShareAI<\/a> e o refer\u00eancia da API<\/a>, depois combine a integra\u00e7\u00e3o com suas pr\u00f3prias verifica\u00e7\u00f5es de pol\u00edticas e observabilidade.<\/p>\n\n\n\n Use este checklist ao adicionar limites em torno de chamadas de modelos de produ\u00e7\u00e3o:<\/p>\n\n\n\nO que validar antes que o usu\u00e1rio veja o resultado<\/h2>\n\n\n\n
Escolha bloquear, permitir ou revisar o comportamento deliberadamente<\/h2>\n\n\n\n
Mantenha o papel do ShareAI claro<\/h2>\n\n\n\n
\n
Um checklist pr\u00e1tico de implementa\u00e7\u00e3o<\/h2>\n\n\n\n
\n