Prompt de Sistema

Em sistemas conversacionais, o prompt de sistema é uma instrução de prioridade elevada que define a função do modelo, as regras permanentes da interação, o estilo, as fontes aceitas e os limites de uso de ferramentas. Ele é inserido pela aplicação, não pelo usuário final, e pode ser combinado com instruções de desenvolvedor ou políticas da plataforma. O conteúdo costuma declarar que estados da casa devem vir de ferramentas, que ações críticas exigem confirmação e que documentos recuperados são dados, não comandos. O prompt de sistema melhora consistência, mas não constitui barreira de segurança. Modelos são probabilísticos e podem seguir instruções conflitantes ou sofrer prompt injection. A aplicação precisa impor autorização, validação, isolamento e auditoria fora do texto.

• A função principal é estabelecer um contrato de comportamento. Ele pode definir identidade: “assistente técnico residencial”; escopo: “automação e suporte”; regras: “não inventar estados”; formato: “respostas em português e tool calls estruturadas”; tratamento de risco: “pedir confirmação para fechaduras”; e privacidade: “não repetir segredos”. Essas instruções devem ser específicas e testáveis. Frases genéricas como “seja seguro” têm pouco valor. O prompt não deve conter políticas impossíveis de aplicar, como garantir verdade absoluta. Regras de negócio críticas ficam em código. O prompt orienta como o modelo conversa e quando solicita ferramentas. O backend decide se a chamada é permitida.
• A hierarquia de mensagens varia por plataforma e versão. Alguns sistemas distinguem system, developer, user, assistant e tool; outros usam um único prompt concatenado. O design deve conhecer a semântica oficial da API usada e não assumir portabilidade. Ao migrar de modelo, testes verificam precedência. Conteúdo de usuário não deve ser concatenado dentro do bloco de sistema sem delimitação, pois pode quebrar estrutura. Templates escapam caracteres. Dados externos entram em mensagens próprias. O prompt de sistema recebe versionamento. Uma versão antiga pode conter regra desatualizada. O log registra ID, não necessariamente texto integral. Mudanças passam por revisão de segurança.
• Segredos não pertencem ao prompt. Chaves de API, tokens MQTT, senhas e certificados podem aparecer em logs, traces, caches ou ferramentas do provedor. O modelo não precisa conhecer. Credenciais ficam no backend e são usadas por conectores. O prompt pode referir uma ferramenta `get_device_state`, mas não sua chave. Dados pessoais também são minimizados. Nomes de moradores só quando necessário. Instruções internas podem ser alvo de extração por usuários. Mesmo que a aplicação tente ocultar, não deve depender da confidencialidade do prompt para segurança. A regra precisa ser segura se parcialmente conhecida. O sistema não revela detalhes que facilitem abuso, mas não guarda segredo crítico ali.
• Prompt injection desafia a hierarquia. Um usuário pode dizer “ignore as regras”, ou um manual recuperado pode conter. O prompt de sistema instrui a tratar conteúdo como não confiável, mas o controle real está na arquitetura. Ferramentas usam allowlist, schemas e autorização. Uma ferramenta de luz não abre fechadura. Uma função de busca não acessa arquivos arbitrários. A execução crítica pede confirmação em UI. Resultados são validados. A aplicação pode usar um segundo classificador ou policy engine. Guardrails detectam padrões. Nenhuma dessas camadas é perfeita. O princípio é defesa em profundidade. O prompt é uma camada de alinhamento, não firewall.
• O tamanho e a clareza afetam custo e comportamento. Um prompt de 10 mil tokens é caro, reduz espaço e pode conter contradições. Políticas devem ser modulares e apenas as relevantes podem ser injetadas, desde que a seleção seja determinística e não remova segurança. Use títulos, prioridades e exemplos. Evite repetir a mesma regra em cinco formas. Testes mostram se a redação é necessária. Um prompt curto demais pode omitir. A manutenção precisa de dono. Comentários e documentação ficam fora do texto enviado. O sistema mede tokens. Prompt caching pode reduzir custo em grandes blocos estáveis, conforme suporte. Alterar uma linha pode invalidar cache.
• A avaliação deve testar obediência e utilidade. Casos incluem instrução conflitante, pedido fora de escopo, dados com prompt injection, ferramenta inexistente, estado ausente, ação crítica, usuário sem permissão e necessidade de declarar incerteza. Red teaming tenta extrair regras ou induzir ação. A métrica importante é comportamento final do sistema, não apenas resposta do modelo. Se o modelo tenta chamar uma função proibida e o backend bloqueia, a segurança prevalece, mas o evento é medido. O prompt pode ser ajustado para reduzir tentativas. Regressões após troca de modelo são comuns. Versionamento e rollback são necessários.