A escolha de implantação precisa conectar requisitos da empresa ao caminho real da aplicação e dos dados. Comece pelo trabalho que será realizado e só então compare ambientes, integrações e responsabilidades de operação.
Descreva o que precisa funcionar
Liste as pessoas, agentes, canais, fontes e sistemas que participam da operação. Para cada componente, registre sua função e dependências. Um chat interno que consulta documentos, uma comunicação ativa e um fluxo que altera o sistema financeiro podem ter requisitos diferentes, mesmo quando usam a mesma plataforma.
Pergunte quais restrições já foram definidas pela empresa e quem pode esclarecê-las. Separe exigências firmes de preferências e de pontos em investigação. “Queremos infraestrutura própria” pode ser uma decisão ou uma forma inicial de expressar preocupações com acesso, disponibilidade ou localização dos dados. Entender a necessidade evita escolher uma modalidade antes de saber o que ela deve atender.
Acompanhe armazenamento e processamento
Desenhe o caminho de uma informação desde a entrada até sua utilização e seus registros. Identifique onde o arquivo fica, quem extrai seu conteúdo, qual modelo recebe a consulta e onde resultados, índices, cópias e logs são mantidos. A aplicação pode estar no ambiente da empresa e ainda consultar um serviço externo.
Para cada saída, anote o conteúdo enviado, a finalidade, o destino e o responsável pela configuração. Considere serviços auxiliares, como busca, transcrição ou monitoramento, quando fizerem parte do desenho. Não conclua que os dados permanecem em um perímetro apenas pela localização de um banco. O caminho precisa ser conferido com a equipe técnica na implantação específica.
Distribua o trabalho de operação
Defina quem provisiona o ambiente, administra acessos, mantém integrações, atualiza componentes e acompanha disponibilidade. Inclua como incidentes são comunicados e quem pode intervir. Ter uma aplicação na infraestrutura do cliente não define, por si só, quem será responsável por cada uma dessas atividades.
Considere também mudanças futuras. Quem aprova uma nova fonte de dados ou um novo modelo? Quem revê o fluxo quando um sistema altera sua API? Como serão tratados testes e retorno a uma versão anterior? Registre responsabilidades de negócio e de tecnologia, porque a continuidade depende tanto do funcionamento técnico quanto da equipe que utiliza o resultado.
Compare desenhos com os mesmos requisitos
SaaS é o uso de uma aplicação do provedor em infraestrutura de nuvem: o cliente utiliza o serviço e suas configurações disponíveis, enquanto a infraestrutura subjacente é operada pelo fornecedor. A localização, o acesso aos dados e as responsabilidades do serviço ainda precisam ser conferidos no desenho e nas condições da oferta.
Implantação assistida, neste guia, significa implantação na infraestrutura do cliente com apoio da Starya. Provisionamento, atualizações, suporte e operação precisam de responsáveis combinados. O termo não pressupõe um pacote de instalação autônoma nem funcionamento sem conexão externa.
Leve a mesma lista de necessidades para comparar SaaS e implantação assistida no ambiente da empresa. Para cada opção, registre o que é atendido, o que exige configuração, o que depende de desenvolvimento e o que ainda não foi confirmado. Um diagrama de referência ajuda a conversar, mas não demonstra que todos os componentes estão disponíveis naquela modalidade.
Escolha um cenário representativo para validar o desenho antes da ampliação. Confira acessos, circulação da informação, comportamento das integrações e caminho de suporte. Anote também o que não foi testado. A conclusão útil é uma decisão com condições explícitas, e não a indicação de um ambiente como universalmente mais seguro, mais barato ou mais simples.
Exemplo ilustrativo · sem dados de cliente
O documento está na empresa; a consulta usa um serviço externo
Exemplo ilustrativo: uma equipe quer um assistente para consultar procedimentos internos. Os arquivos ficam na infraestrutura da empresa, mas a proposta de solução envia trechos para um modelo externo. O mapa identifica separadamente o armazenamento do documento e o processamento da pergunta.
A matriz abaixo preenche esse desenho hipotético. Locais e atribuições são propostas para discussão, não a descrição de uma implantação disponível. Os prazos ainda precisam ser definidos: deixar “a confirmar” visível permite localizar quem deve responder antes da escolha.
A equipe responsável verifica quais conteúdos podem seguir por esse caminho. Se a condição não for atendida, o desenho precisa mudar ou o escopo deve ser limitado. Trocar apenas o local do chat não resolve a dependência.
| Componente | Dado | Processamento | Registros | Retenção | Responsável proposto |
|---|---|---|---|---|---|
| Repositório de origem | Procedimentos internos e suas versões. | Armazenamento no ambiente do cliente. | Arquivo, versão e permissões de leitura. | Prazo a definir; incluir cópias e versões antigas. | Dono do documento e TI do cliente. |
| Extração e busca | Trechos extraídos e índice de busca. | Extração e consulta no ambiente do cliente. | Fonte, versão e resultado da indexação. | A definir; prever exclusão no índice quando a fonte for retirada. | TI do cliente, com apoio de configuração da Starya. |
| Chat e orquestração | Pergunta, trechos selecionados e resposta. | Aplicação no ambiente do cliente; envia trechos ao modelo externo. | Conversa e referência da consulta, conforme configuração. | Prazo e conteúdo do histórico a confirmar. | Responsável pela aplicação e pelo acesso dos usuários. |
| Modelo externo | Pergunta e trechos autorizados enviados à API. | Infraestrutura do provedor; região a confirmar. | Registros do provedor a conferir na modalidade contratada. | Condições de retenção, exclusão e uso a confirmar com o provedor. | Responsável pela contratação e administrador da integração. |
| Logs e suporte | Identificação da execução e falhas; conteúdo a minimizar. | Coleta no ambiente do cliente; acesso de suporte a combinar. | Eventos técnicos e acessos de suporte, conforme desenho. | Prazo, cópias de segurança e exclusão a definir. | Responsável operacional; acesso da Starya conforme acordo. |
A pergunta para decidir é concreta: quais trechos podem sair, para qual destino e sob quais condições? Enquanto região, retenção ou acesso de suporte estiverem em aberto, essas condições não estão confirmadas. A matriz ajuda a testar o desenho; manter os arquivos na empresa, por si só, não demonstra soberania sobre todo o caminho dos dados.
Quando o caminho precisa mudar
Se a empresa já tem uma plataforma de dados ou um provedor homologado, inclua isso como ponto de partida. Se um componente ainda não existe na modalidade desejada, registre a dependência e avalie um recorte viável. Quando houver restrição de conectividade, valide também atualização, suporte e operação; não suponha funcionamento offline por usar infraestrutura própria.
Um ponto de atenção: Presumir que infraestrutura própria impede qualquer circulação de dados para fora.
O roteiro está pronto para avançar quando…
- Componentes e circulação dos dados estão descritos, incluindo serviços externos.
- Requisitos e responsabilidades têm responsáveis por sua confirmação.
- A opção escolhida registra condições, dependências e verificações ainda pendentes.
Leve o mapa e as perguntas para uma conversa técnica. Use a comparação de ambientes como apoio visual e confirme as capacidades disponíveis para o seu contexto antes de definir a implantação.
Seu roteiro
Preencha com sua equipe.
Registre o que já sabe e o que ainda precisa confirmar. As respostas permanecem em memória, sem envio.
Referências para aprofundar
- NIST SP 800-145 · definição de SaaS ↗
Define SaaS como uso de aplicações do provedor em infraestrutura de nuvem, cuja infraestrutura subjacente não é administrada pelo cliente. A definição não determina onde uma implantação específica processa ou retém dados.