O detalhe mais importante não é a Siri passar a “conversar com outro chatbot”. É a possibilidade de um modelo externo interpretar um pedido e devolver uma ação estruturada para a Siri executar com as permissões do sistema. Segundo o Sapo.pt, frameworks privadas encontradas no iOS 27 e no macOS Golden Gate apontam nessa direção — mas isso ainda não significa que exista uma API pública pronta para desenvolvedores.
Na prática, essa separação pode resolver um problema recorrente nos assistentes: modelos de linguagem entendem pedidos flexíveis, mas nem sempre têm acesso seguro às funções do dispositivo. Se a arquitetura descrita se confirmar, um modelo como Claude ou ChatGPT poderia interpretar a intenção, enquanto a Siri continuaria responsável por executar ações em apps do sistema, como Lembretes.
O que a Model Delegation API pode mudar na Siri
De acordo com a reportagem, a Model Delegation API permite que um modelo de terceiros apareça como uma extensão da Siri. O exemplo divulgado no X mostra o Claude sendo selecionado no menu “Ask…” do Mac e recebendo um pedido para criar um lembrete. O modelo entende o pedido e devolve a tarefa à Siri, que realiza a ação no app Lembretes.
Esse fluxo é diferente de simplesmente abrir um chatbot e pedir que ele explique como criar um lembrete. O modelo participa da interpretação, mas a execução permanece no ambiente controlado pela Apple. Isso importa porque criar um lembrete exige uma ação real no dispositivo, não apenas uma resposta em texto.
A reportagem também descreve um segundo exemplo: o Claude gera um arquivo CSV a partir de uma solicitação em linguagem natural e retorna o resultado pela interface da Siri. É uma demonstração interessante, mas não permite concluir, por si só, quais formatos, permissões ou limites estarão disponíveis na versão final do sistema.
Interpretação não é execução: a distinção técnica essencial
Em uma arquitetura segura de assistente, eu separaria pelo menos três responsabilidades:
- Interpretação: transformar “me lembre de revisar o deploy amanhã às nove” em uma intenção e parâmetros compreensíveis.
- Autorização: verificar se o usuário permite aquela ação e se o app tem as permissões necessárias.
- Execução: gravar o lembrete, criar o arquivo ou chamar a função aprovada pelo sistema.
O modelo é bom em lidar com linguagem ambígua. Já a camada de execução precisa ser previsível, validável e sujeita às permissões do usuário. Se o modelo puder acessar qualquer app ou arquivo sem uma fronteira explícita, uma interpretação errada vira uma ação indevida.
Por isso, vejo valor no padrão descrito: o modelo propõe ou estrutura uma ação; o sistema operacional decide como executá-la. Isso não elimina riscos, mas é melhor do que entregar ao modelo acesso irrestrito a recursos do dispositivo.
Como isso se compara ao ChatGPT, aos Atalhos e ao App Intents
A integração do ChatGPT com a Siri, já mencionada na reportagem como existente, é uma referência útil, mas não devemos presumir que Claude e ChatGPT terão exatamente as mesmas capacidades. Cada integração pode ter diferenças de interface, disponibilidade, limites de contexto e tratamento de dados.
Os Atalhos oferecem automações explícitas: o usuário monta uma sequência de ações, com entradas e saídas relativamente previsíveis. Eles são ótimos quando o fluxo já é conhecido. Um modelo delegado seria mais útil quando o pedido chega em linguagem natural e precisa ser convertido em uma ação adequada.
O App Intents, por sua vez, é a tecnologia pública da Apple para expor ações de um app a recursos do sistema, incluindo Siri e Atalhos. É a opção que eu avaliaria hoje para tornar uma funcionalidade de um app invocável por voz ou automação. A existência de frameworks privadas de delegação não transforma essas frameworks em uma API disponível para aplicativos de terceiros.
Em um backend próprio, também é possível implementar chamadas de ferramentas (“tool calling”) com modelos de diferentes fornecedores. A diferença é que o desenvolvedor controla o orquestrador e precisa construir autenticação, autorização, validação, observabilidade e integração com cada serviço. A delegação descrita pela reportagem sugere uma experiência mais integrada ao sistema, mas os detalhes públicos ainda são limitados.
Na Prática: expondo uma ação segura com App Intents
Enquanto não houver documentação pública da suposta Model Delegation API, eu não tentaria integrar meu app às frameworks privadas. Para uma ação própria, usaria App Intents e manteria a execução dentro do app, com parâmetros tipados e permissões claras.
- Defina uma ação pequena: por exemplo, criar um lembrete com um título informado pelo usuário.
- Declare os parâmetros: evite receber um bloco de texto livre quando sua ação exige campos específicos.
- Valide antes de executar: normalize o título e rejeite valores vazios ou inválidos.
- Peça acesso no momento adequado: explique por que o app precisa acessar Lembretes e trate a recusa.
- Retorne um resultado simples: confirme o que foi feito sem expor dados desnecessários.
Este exemplo em Swift mostra uma ação de App Intents que cria um lembrete usando EventKit. Ele não chama Claude nem usa qualquer framework privada; demonstra apenas uma fronteira pública para uma ação do app. Para usar acesso completo a lembretes, configure também a descrição de privacidade exigida pelo sistema no projeto.
import AppIntents
import EventKit
struct CreateReminderIntent: AppIntent {
static var title: LocalizedStringResource = "Criar lembrete"
@Parameter(title: "Título")
var title: String
func perform() async throws -> some IntentResult {
let cleanTitle = title.trimmingCharacters(
in: .whitespacesAndNewlines
)
guard !cleanTitle.isEmpty else {
throw IntentError.emptyTitle
}
let store = EKEventStore()
try await store.requestFullAccessToReminders()
guard let calendar = store.defaultCalendarForNewReminders() else {
throw IntentError.noReminderList
}
let reminder = EKReminder(eventStore: store)
reminder.title = cleanTitle
reminder.calendar = calendar
try store.save(reminder, commit: true)
return .result()
}
}
enum IntentError: LocalizedError {
case emptyTitle
case noReminderList
var errorDescription: String? {
switch self {
case .emptyTitle:
return "Informe um título para o lembrete."
case .noReminderList:
return "Não foi encontrada uma lista de lembretes."
}
}
}Esse código ainda precisa ser testado no alvo e na versão do SDK escolhidos, além de incluir as configurações de privacidade e disponibilidade adequadas. O ponto arquitetural é o mais importante: qualquer modelo que venha a sugerir essa ação não deve substituir a validação do app nem a autorização do sistema.
Implicações para quem desenvolve software
Se a delegação chegar como recurso público, os apps poderão precisar projetar ações pensando em entrada ambígua. Um usuário pode pedir “organize isso para amanhã”, mas o app precisa saber o que “isso” significa, qual horário usar e se deve criar uma tarefa, um evento ou um lembrete.
Eu trataria cada operação como uma função com contrato explícito. Parâmetros obrigatórios, limites, respostas de erro e confirmação de ações destrutivas devem continuar sob controle do app. O modelo pode melhorar a interface de linguagem natural; não deve virar a fonte de verdade dos dados nem decidir sozinho que uma ação sensível está autorizada.
Também vale observar a experiência de falha. O modelo pode estar indisponível, a rede pode cair ou a resposta pode vir incompleta. Um bom app oferece um caminho alternativo — formulário, busca ou atalho — em vez de deixar a tarefa inacessível quando a IA falhar.
Erros comuns ao integrar modelos a ações do sistema
- Usar APIs privadas em produção: frameworks internas podem mudar sem aviso, não ter suporte e causar rejeição ou instabilidade. Inspecionar um binário não equivale a receber um contrato público.
- Confiar cegamente na saída do modelo: valide tipos, faixas e campos obrigatórios antes de chamar qualquer ferramenta.
- Confundir resposta convincente com ação concluída: só confirme sucesso depois que a operação real retornar sem erro.
- Dar permissões amplas demais: solicite o acesso necessário para a tarefa, explique o motivo e respeite a escolha do usuário.
- Ignorar privacidade e retenção: antes de enviar dados a um fornecedor de IA, defina quais informações saem do dispositivo e como são tratadas.
- Não prever ambiguidades: se faltarem data, destino ou contexto, peça esclarecimento em vez de inventar parâmetros.
O que ainda não dá para afirmar sobre o iOS 27
Uma framework privada encontrada no sistema é um indício técnico, não uma promessa de produto. A Apple pode alterar a implementação, limitar o recurso a determinados parceiros ou não disponibilizá-lo para desenvolvedores independentes. O mesmo cuidado vale para os vídeos: eles demonstram um comportamento observado, mas não substituem documentação, requisitos oficiais ou testes em uma versão final.
Também não sabemos, com base apenas na reportagem, como será o consentimento para enviar pedidos a modelos externos, quais dados acompanharão cada solicitação ou se o usuário poderá escolher o provedor padrão. Esses detalhes serão decisivos para empresas que trabalham com dados internos, código-fonte ou informações pessoais.
FAQ: delegação da Siri para Claude e ChatGPT
A Model Delegation API já está disponível para desenvolvedores?
Segundo o Sapo.pt, a API encontrada é privada. Até haver documentação pública e suporte oficial, não recomendo usá-la em aplicativos distribuídos.
O Claude poderá executar ações diretamente no iPhone?
O exemplo relatado aponta para um fluxo em que o modelo interpreta o pedido e a Siri executa a ação. Isso não prova que o Claude terá acesso direto e irrestrito ao sistema, nem esclarece quais ações serão permitidas.
Qual tecnologia devo usar hoje para integrar ações do meu app com a Siri?
Para ações expostas pelo próprio app, avalie App Intents e, quando fizer sentido, Atalhos. Eles são caminhos públicos; a escolha depende de como o usuário deve descobrir e iniciar a ação.
Essa delegação elimina a necessidade de validar respostas de IA?
Não. O app ainda deve validar parâmetros, verificar permissões, tratar falhas e confirmar a execução real. Linguagem natural melhora a entrada, mas não substitui regras de negócio.
Minha leitura
A ideia mais interessante não é colocar mais um chatbot dentro da Siri. É permitir que modelos diferentes cuidem da interpretação, enquanto o sistema operacional mantém controle sobre permissões e execução. Se a Apple publicar uma API estável com esse desenho, haverá uma oportunidade real para criar interfaces mais naturais sem abrir mão de limites de segurança.
Até lá, eu trataria os vídeos e as frameworks encontradas como sinais de uma direção possível, não como uma especificação. Para código de produção, usaria APIs públicas, contratos explícitos e confirmação antes de ações sensíveis.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.