16 · Limites, cotas, retenção e privacidade

Este capítulo traz todo limite a que uma requisição está sujeita, por quanto tempo o que você envia e o que nós produzimos é guardado, o que é guardado para sempre, o que nunca é guardado, e o que chega aos nossos servidores. Os números são gerados a partir dos planos que o serviço aplica; as declarações de retenção são as que o próprio documento de retenção do serviço faz, nas suas palavras.

Limites

Cada chave está sujeita a estes, pelo seu plano. Uma chave pode ser criada mais restrita, nunca mais ampla:

Cada chave	Gratuito	Pago	Enterprise
requests_per_minute: requisições por minuto	20	120	500
concurrent_solves: jobs rodando ao mesmo tempo	1	4	10
concurrent_solves_forest: jobs de random forest rodando ao mesmo tempo	1	1	1
streams: streams abertos ao mesmo tempo	32	32	32
monthly_solve_seconds: segundos de resolução por mês	1.800	10.800	360.000
wall_budget_ceiling_seconds: o maior orçamento de tempo que um job pode pedir, em segundos; um maior é reduzido a ele	60	900	900
max_upload_bytes: o maior arquivo, em bytes	1.048.576	8.388.608	31.457.280
max_upload_bytes_forest: o maior arquivo de random forest, em bytes	10.485.760	31.457.280	536.870.912
artifact_retention_days: dias em que um artefato continua disponível para download	30	30	30
max_proof_bytes: a maior prova FRAT guardada, em bytes	268.435.456	268.435.456	268.435.456

Por mês, os medidores da sua organização, somados sobre todas as chaves e todas as máquinas:

Por mês, ou numa requisição	Gratuito	Pago	Enterprise
plan_calls: Planos lidos, por mês.	1.000	100.000	sem limite
compute_runs: Passos de cálculo executados, por mês.	100	10.000	sem limite
compute_seconds: Segundos de cálculo, por mês.	300	30.000	sem limite
cache_hits: Respostas servidas pelo cache, por mês.	sem limite	sem limite	sem limite
feedback_records: Registros de feedback guardados, por mês.	1.000	100.000	sem limite
mine_runs: Execuções do minerador hospedado, por mês.	10	100	sem limite
catalogue_versions: Versões de catálogo registradas, por mês.	10	sem limite	sem limite
tool_checks: Chamadas de ferramentas verificadas aqui, por mês; as verificações do próprio runtime são contadas nos seus relatórios de uso.	10.000	1.000.000	sem limite
graph_checks: Jobs de grafo, por mês.	50	5.000	sem limite
answer_calls: Respostas que um modelo compôs a partir dos seus documentos, por mês: uma por chamada ao modelo.	—	20.000	sem limite
catalogue_tools: Ferramentas que um catálogo pode declarar.	50	sem limite	sem limite
graph_nodes: Nós que um grafo pode ter, depois de os seus subgrafos serem incorporados em cada uso.	40	sem limite	sem limite

Alguns limites valem para todos os planos:

• Um upload é limitado ao menor entre o max_upload_bytes da sua chave e o limite do próprio modo, conferido contra o tamanho declarado e de novo contra os próprios bytes.
• Um orçamento de tempo acima do wall_budget_ceiling_seconds da sua chave é reduzido a ele, não recusado, e o run.clamped_by do job diz isso. Os jobs de random forest têm o seu próprio teto, por propriedade.
• Streams: no máximo 8 num job, e 60 novos por minuto por chave (capítulo 9).
• A cota é conferida quando um job é enviado, não enquanto ele roda: um job que começou dentro da cota termina.

A página Usage do console mostra cada medidor deste mês contra o seu teto, por dia.

Retenção

O que você envia e o que um job produz são guardados pelo artifact_retention_days da sua chave, 30 dias por padrão, e depois apagados. Uma retenção (hold) pode guardar um artefato por mais tempo, e nunca em silêncio: uma retenção colocada automaticamente por um defeito acrescenta no máximo 30 dias, com um motivo fixo, e uma colocada por uma pessoa, a pedido escrito seu ou por motivo legal, é auditada e mostrada na página Storage do seu console até ser retirada.

O que é apagado em 30 dias

Todo artefato e toda entrada enviada além da sua janela. Os bytes deixam de existir no banco de dados. Um job noturno os apaga, depois do backup noturno, para que uma restauração do backup da noite anterior tenha os arquivos que existiam naquela noite.

O que não desaparece em 30 dias

Nas palavras do documento de retenção do serviço, que pede para ser citado em vez de resumido (em inglês, como ele foi escrito):

An encrypted copy exists off-site until the backups taken before the deletion expire. Stored objects are rows, so they are inside every weekly base backup and in the WAL archive from the moment they were written. Each is locked for 35 days from the day it was uploaded and deleted two days after that, and a base backup is the whole database — one deleted object cannot be cut out of it. So a file deleted here on day 30 remains in the newest base taken before that day, and leaves when that base expires: up to 35 days after the deletion.

It is age ciphertext there, and the identity that decrypts it is held in escrow, off every host the service runs on. The service itself cannot read it, and no customer can. The people who operate the service can reach that escrow, and its custodian is named there; a restore is the reason they would.

Em português: uma cópia cifrada existe fora do nosso servidor até os backups feitos antes da exclusão expirarem, ou seja, até 35 dias depois da exclusão. Ela está cifrada, e a identidade que a decifra fica guardada em custódia, fora de todo host em que o serviço roda: o próprio serviço não consegue lê-la, e nenhum cliente consegue; as pessoas que operam o serviço conseguem chegar a essa custódia, e uma restauração é o motivo pelo qual chegariam.

Duas razões fazem disso a escolha certa: o backup não pode propagar exclusões, ou um host adulterado poderia apagar a evidência do que fez apagando localmente; e a janela do backup tem de durar mais que a do artefato, ou não haveria backup no dia em que alguém descobre um erro. Uma restauração termina com uma exclusão deliberada, para nunca trazer de volta o que já tinha sido apagado.

O que é ocultado em 90 dias

As cópias do próprio banco de dados do que você enviou em linha: uma política colada numa requisição, e um certificado embutido no resultado de um job. Apagar os arquivos mantendo estas tornaria a promessa falsa da forma menos visível que existe.

O que é guardado para sempre

O registro de exclusão de cada artefato: o seu id, papel, nome de arquivo, digest, tamanho, hora de criação e hora de exclusão. Também o veredito de cada job, os seus diagnósticos e o seu registro de uso. Isso vale para os dois lados: você pode provar que existiu um certificado com aquele digest, e nós podemos provar quando o apagamos.

Um artefato apagado responde 410 artifact_purged, não 404: ele existiu, e o seu registro diz isso.

Feedback

Os registros de feedback são guardados pela retenção de artefatos da sua chave, ou pelo número de dias que você definir na página Settings do console, de 1 a 3.650. Um registro só contém as palavras avaliadas e a leitura que o roteador fez delas (capítulo 25).

Arquivos de prova

Uma prova FRAT pedida com frat_proof é guardada como dois artefatos proof, o CNF e o registro FRAT, sob a mesma retenção de qualquer artefato, e contada contra o max_proof_bytes da sua chave por job. Uma prova é conferida pelo worker antes de ser guardada, e é descartada, nunca o veredito, quando falha nessa conferência ou excederia o limite. O certificado então diz por quê, em proof_log_omitted: self_check_failed ou artefact_limit, este último com o tamanho que ela teria.

O console

Uma sessão do console dura doze horas. Todo login e toda mudança ficam no histórico administrativo, que só recebe acréscimos e que uma proprietária lê.

O que chega aos nossos servidores

O que fica na sua máquina: as conversas dos seus agentes, as suas chamadas de ferramenta e os seus resultados, os dados, a função e o resultado de um cálculo, e os documentos de que os seus agentes respondem e o seu índice. O runtime licenciado decide ali os planos e as verificações de ferramentas; só contagens saem dele (capítulo 38). Não guardamos nenhuma sessão, nenhum argumento de chamada de ferramenta e nenhum resultado de ferramenta, nem as palavras de um turno, exceto as que um registro de feedback carrega.

O que é enviado, e verificado na sua máquina antes: uma resolução e as suas entradas, as descrições das ferramentas de um catálogo, uma planilha de regras, um prompt de escrita de guardrails, e o registro de feedback de um polegar, que traz as palavras do turno que ele avalia. Cada um é verificado em busca de endereços de e-mail, números de telefone, números de cartão de pagamento, IBANs, números do National Insurance do Reino Unido, números de CPF e os identificadores que você lista como seus. Uma ocorrência não envia nada (capítulo 15).

O que nunca é guardado: uma chave de modelo e um prompt de escrita de guardrails viajam até o worker e são apagados ao serem lidos; o job guarda o digest e o tamanho do prompt, nunca o seu texto (capítulo 13). Os corpos de requisição e de resposta não vão para os logs.

Nunca usado para treinamento. O que você envia é usado para responder à sua requisição, e o seu feedback para melhorar o vocabulário da sua própria organização. Nenhum dos dois é usado para treinar modelos, nossos ou de quem quer que seja.

Os limites

• A retenção é a exclusão do nosso banco de dados no fim da janela, e dos backups cifrados fora do servidor até 35 dias depois disso, como citado acima. Não é um apagamento instantâneo em todo lugar.
• Uma retenção prolonga um artefato, e é mostrada a você enquanto dura.
• A verificação antes do envio encontra os tipos de dado que nomeia, e os identificadores que você lista; ela não encontra todo tipo de dado pessoal que existe.