Termos de Serviço na Nuvem

Acordos cloud em operações de contentores

Termos de serviço na nuvem são as condições contratuais que definem como uma aplicação alojada na cloud pode ser usada, que nível de serviço o fornecedor assume, como os dados são protegidos e o que acontece em caso de falha, suspensão ou fim do contrato.

Em logística de contentores, este documento contratual não é apenas “letra pequena”. Uma plataforma de gate, parque, faturação, EDI, tracking ou gestão de equipamentos pode estar ligada a processos críticos: entrada e saída de camiões, disponibilidade de contentores vazios, planeamento de movimentos no yard, integração com linhas marítimas, agentes, alfândega ou sistemas de terminal. Uma condição mal lida pode afetar tempos de atendimento, reconciliação de movimentos ou acesso ao histórico operacional.

Há ainda uma confusão comum: em terminais, “TOS” também significa Terminal Operating System. Neste artigo, TOS refere-se às condições do fornecedor de uma solução cloud, não ao sistema operacional do terminal.

Pontos do contrato que afetam a operação

Antes de adoptar uma aplicação cloud para terminal, depot, parque ou transporte, a equipa operacional e a equipa de IT devem confirmar se o acordo cobre a forma como o serviço será usado no dia a dia.

• Âmbito do serviço: módulos incluídos, como gate, yard, booking, inventário, faturação, EDI/API, relatórios, gestão documental e integrações externas.
• SLA: disponibilidade contratada, janelas de manutenção, tempos de resposta do suporte e tratamento de incidentes críticos.
• Dados operacionais: propriedade e acesso a registos de movimentos, manifestos, fotografias, selos, danos, pesagens, timestamps, utilizadores e logs de auditoria.
• Segurança: autenticação, perfis de acesso, encriptação, cópias de segurança, localização dos dados e conformidade com RGPD.
• Integrações: limites de API, responsabilidades por falhas de EDI, formatos suportados e retenção de mensagens.
• Saída do serviço: exportação de dados, formato dos ficheiros, prazo de disponibilidade e apoio na migração.

SLA em números, não em promessas vagas

Num ambiente de contentores, “alta disponibilidade” ou “suporte rápido” dizem pouco. O contrato deve traduzir esses compromissos em parâmetros mensuráveis, por exemplo:

• Disponibilidade mensal: 99,5%, 99,9% ou 99,95%, indicando o que fica excluído por manutenção programada.
• RTO: tempo máximo previsto para repor o serviço após incidente, por exemplo 2 ou 4 horas.
• RPO: perda máxima aceitável de dados, por exemplo 15 minutos ou 1 hora.
• Tempo de resposta do suporte: por severidade, como 30 minutos para incidente crítico durante horário operacional.
• Limites de integração: chamadas API por minuto, tamanho máximo de ficheiros EDI ou número de mensagens em fila.

Estes valores ajudam a perceber o risco real. Um depot com 200 movimentos de gate por dia pode tolerar uma interrupção curta de reporting; já uma paragem no registo de entradas e saídas durante o pico da manhã pode gerar filas, erros de inventário e disputas com transportadores.

Política de utilização: onde aparecem os atritos

A política de utilização define o que o cliente pode ou não fazer com a aplicação. Em operações logísticas, deve ser lida com atenção quando existem integrações automáticas, várias entidades envolvidas e utilizadores externos.

Convém clarificar:

• se é permitido criar acessos para transportadores, agentes, clientes ou subcontratados;
• se há limite de utilizadores simultâneos no gate, backoffice ou equipa de planeamento;
• se o carregamento massivo de ficheiros EDI pode ser bloqueado por consumo excessivo;
• se integrações feitas por terceiros são aceites ou apenas APIs aprovadas pelo fornecedor;
• que situações podem levar à suspensão do acesso, como tentativas de login, tráfego anómalo ou uso indevido de credenciais.

Estas regras têm de encaixar na operação real. Um terminal ou parque não trabalha como uma empresa de escritório: há picos por escala de navio, cut-offs de exportação, janelas de camiões, alterações de booking e validações externas que podem concentrar muito tráfego em períodos curtos.

Exemplo operacional

Um parque de contentores usa uma aplicação cloud para registar entradas, saídas, inspeções de danos e disponibilidade de vazios. Às 08:00, vários transportadores chegam para levantar contentores associados a bookings de exportação. Ao mesmo tempo, uma integração EDI envia atualizações de stock para uma companhia marítima.

Se o contrato não definir prioridades de suporte, limites de API e procedimento de contingência, a equipa pode ficar sem saber se deve continuar em modo manual, aguardar reposição ou limitar integrações para manter o gate a funcionar. Um acordo bem escrito indica quem é contactado, em que prazo, que dados ficam preservados, como são reconciliados movimentos offline e quando a ocorrência passa a incumprimento de SLA.

Responsabilidades do fornecedor e do cliente

O fornecedor deve garantir infraestrutura, monitorização, backups, segurança da aplicação, documentação técnica e suporte conforme contratado. Também deve comunicar manutenções e incidentes com antecedência e detalhe suficiente para a operação se preparar.

O cliente continua responsável por configurar utilizadores, remover acessos de colaboradores que saem, proteger credenciais, validar dados introduzidos e manter processos internos de contingência. A cloud reduz trabalho técnico, mas não elimina governação operacional.

No contexto da ContPark, esta distinção é relevante porque as aplicações para parques e operações de contentores lidam com eventos sensíveis: movimentos, estados de equipamento, documentos, fotografias, cobranças e integrações com parceiros. Num cenário de gate ou depot, por exemplo, uma falha na leitura de um movimento, numa fotografia de dano ou numa mensagem EDI pode afetar faturação, disponibilidade de equipamento e responsabilidade perante cliente ou armador.

Checklist antes de aceitar

• Confirmar se o SLA cobre os horários reais da operação, incluindo fins de semana, feriados ou turnos noturnos.
• Verificar RTO, RPO, backups e processo de recuperação.
• Garantir exportação de dados em formato utilizável, como CSV, XLSX, XML, JSON ou base de dados documentada.
• Clarificar responsabilidades em falhas de EDI, API, internet local ou sistemas de terceiros.
• Definir contactos, severidades e escalamento para incidentes no gate, yard, faturação ou integrações.
• Testar o procedimento manual para movimentos críticos antes da entrada em produção.

Antes da assinatura, reveja o SLA, confirme como os dados podem ser exportados e valide o plano de contingência para gate, yard e integrações. O contrato deve permitir continuar a operar, reconciliar movimentos e recuperar informação sem transformar uma falha técnica num problema comercial com clientes, transportadores ou linhas marítimas.