Um arquivo .cursorrules do Cursor afinado para o engenheiro in-house de Legal Ops (ou Legal Ops manager que codifica): construindo configurações de CLM, escrevendo MCP servers para tools de AI legal, automatizando intake, e integrando Ironclad, Agiloft, e-billing, e sistemas de matter-management. O artefato é um arquivo — apps/web/public/artifacts/cursor-rules-legal-ops-engineer/.cursorrules — que você solta no diretório .cursor/rules/ do seu projeto.

A propriedade definidora do código de legal-ops é que ele toca dados de matter sujeitos a privilégio attorney-client, e contratos que, se vazados, encerram carreiras. Handling de privilégio, auditoria, defaults read-only, e retenção conservadora não são preferências — são a diferença entre uma integração e uma notificação de malpractice. As rules nesse bundle codificam a postura de privilégio da firma para que o AI assistant do Cursor não sugira o tipo de código que termina numa audiência disciplinar da ordem.

Quando usar isso

Você é um engenheiro de Legal Ops, Legal Ops manager que escreve código, ou um engenheiro legal-tech (tipicamente Python ou TypeScript) construindo integrações contra um CLM, sistema de e-billing, ou ferramenta de matter-management. Sua firma tem pelo menos um advogado in-house que assina decisões de vendor de AI. O Cursor é seu IDE.

Quando NÃO usar isso

Você é um vendor SaaS legal-tech construindo produto para escritórios de advocacia. As rules são afinadas para o lado consumidor — o time in-house que vive com exposição de privilégio para sempre — e assumem constraints jurisdicionais/de política de AI que são diferentes em engenharia de produto vendor-side.
Você é um paralegal automatizando tarefas recorrentes via workflows de CLM ou ferramentas no-code. As rules assumem code reviews, version control, e um pipeline de deploy; um operador de workflow no-code não se beneficia.
Sua firma não tem política de AI e não tem escritório do GC para consultar. As rules referenciam “vendors de AI Tier A” repetidamente — sem uma política que defina tiers, a constraint mais load-bearing não está operativa. Tenha a política escrita primeiro.

Setup

Copie o artefato. Pegue .cursorrules do bundle acima (ou baixe o zip) e solte no diretório .cursor/rules/ do seu projeto. O indicador de Project Rules do Cursor confirma que está carregado.
Ajuste a lista de vendor de AI. As rules referenciam “vendors Tier A” genericamente. Edite a seção de handling de privilégio para nomear os vendors Tier A aprovados da sua firma de verdade (ex. Anthropic Claude com acordo de zero-retenção, Microsoft Azure OpenAI sob BAA). Sem isso, as sugestões ficam genéricas.
Defina o destino de auditoria. As rules requerem que toda read e todo write produzam uma entrada de auditoria, mas não ditam onde. Edite a seção “Audit trail” para apontar para o seu destino de auditoria (um objeto custom de CLM, um SIEM, um banco de dados de privileged-access). As rules referenciam o destino por nome nas sugestões.
Defina o secret manager. As rules banem credenciais inline e direcionam o modelo para o seu secret manager de escolha (1Password CLI, Doppler, AWS Secrets Manager, Vault). Escolha um e edite a seção “Secrets and access”.
Teste numa tarefa representativa. Peça pro Cursor: “escreva um script Python que lê contratos do Ironclad com uma tag específica, resume os termos de renovação deles com Claude, e posta um sumário num matter.” O output deve perguntar qual tier do Claude a firma aprovou, onde o log de auditoria vai, e se os contratos são post-effective-date ou em negociação ativa. Se não pergunta, as rules não estão carregadas — verifique o indicador.

O que as rules realmente fazem

O bundle é estruturado em cinco camadas, aplicadas a todo prompt do Cursor:

Um preâmbulo “antes de escrever código, pergunte.” Cinco perguntas que o Cursor superficializa antes de gerar: status de privilégio dos dados, tier do vendor de AI na política da firma, jurisdições envolvidas, read-vs-write, política de retenção. Essas mapeiam diretamente para as perguntas que o escritório de um GC faria numa reunião de vendor-review — preemptivamente.
Orientação tool-specific para Ironclad (endpoints REST, privilégio de workflow-version, logging de metadata de search-query), Agiloft (REST vs SOAP, snake_case, redação em bulk export), LEDES (schemas 1998B/2000, códigos UTBMS, privilégio de billing-narrative), sistemas de matter-management (iManage IsCheckedOut, herança de ACL), e MCP servers para tools legais (defaults read-only, sem exposição de delete_*, audit-log-como-conteúdo-privilegiado).
Defaults para enforçar através de auditoria, handling de privilégio, read-only-by-default, idempotência, schema validation, secrets, e testing. Cada default é concreto: o log de auditoria retém 7+ anos; conteúdo privilegiado é proibido em caches de aplicação; bulk writes lotetam em máximo de 25 registros com preview de dry-run obrigatório.
Anti-patterns para recusar. Padrões específicos que o modelo rejeita: produção como ambiente de teste, pular auditoria “para o protótipo,” fazer cache de conteúdo privilegiado no Redis, mandar conteúdo privilegiado para vendors não-Tier-A mesmo com override do engenheiro.
Uma seção “quando o usuário está errado”. Os atalhos que os engenheiros buscam sob pressão de deadline e que o modelo empurra de volta. A rule single mais cost-saving: recusar mandar conteúdo privilegiado para um vendor de AI não-Tier-A independente de como o usuário enquadra a request, porque a política de AI explicitamente não tem cláusula de override per-engenheiro.

Realidade de custo

Custo de tokens: zero. Cursor rules são contexto local enviado em cada prompt — sem cobrança per-request. O arquivo ocupa 5-6 KB de contexto.
Tempo de setup: ~15 minutos para soltar o arquivo e configurar a lista de vendor, destino de auditoria, e secret manager.
Overhead per-task: o preâmbulo adiciona 1-2 turnos de diálogo. Para uma tarefa de 30 minutos, isso é ruído; para um throwaway de 5 minutos, é pesado. Throwaways envolvendo conteúdo privilegiado não deveriam existir.
Manutenção: ~1 hora por trimestre para revisar o arquivo. Classificações de tier de vendor mudam quando contratos são renovados; regras jurisdicionais evoluem (datas de compliance do EU AI Act pousaram em 2025-26, com enforcement faseado); versões de SDK de CLM derivam. Revisão trimestral com o escritório do GC mantém as rules acuradas.

Como o sucesso se parece

Código que viola privilégio nunca entra em review. As rules superficializam o check de privilégio antes da geração, então a primeira versão do script já referencia o tier correto do vendor e a chamada correta do log de auditoria.
Reuniões de vendor-review ficam mais curtas. Quando o engenheiro chega no escritório do GC para um review de integração nova, a implementação já referencia a política de AI explicitamente; a conversa é “isso atende a política” e não “explica o que você construiu.”
Auditorias de ordem/insurer superficializam um trail limpo. Toda read e write de conteúdo privilegiado tem uma entrada de auditoria. A review anual do malpractice insurer percorre o objeto de auditoria, não a memória do engenheiro.
Engenheiros novos de legal-ops fazem ramp mais rápido. Ler .cursor/rules/legal-ops-engineer.md uma vez ensina a postura de privilégio da firma; o engenheiro novo não precisa absorver um trimestre de feedback de code review para entender quais vendors de AI são aprovados e por quê.

Versus as alternativas

Sem rules de jeito nenhum (status quo). O Cursor gera código legal-tech plausível que viola a política de AI no primeiro run. O custo de um incidente de vazamento de privilégio é meses de resposta da ordem e exposição potencial a professional-liability.
Um doc de convenções de código do time que o escritório do GC escreveu. Funcionalmente perto de nenhuma rule — o doc não é carregado no contexto do AI, então as sugestões não refletem ele. O arquivo de Cursor rules torna o doc operativo em todo prompt.
Uma ferramenta de compliance de AI vendor-side (ex. Croct, Harvey para review de compliance). Pega problemas depois que o código está escrito. Coexiste com as Cursor rules; as rules previnem a violação, a ferramenta de compliance pega o que escapa.

Pontos de atenção

As rules requerem suporte de Project Rules do Cursor. Versões mais antigas do Cursor não carregam .cursorrules. Verifique na versão do Cursor que seu time usa; o indicador no fundo do editor confirma que as rules estão ativas. Guard: inclua um check de uma linha no README do projeto (“Cursor 0.40+; o indicador de rules tem que mostrar ‘legal-ops-engineer.md active’”).
Não super-especifique. Adicionar rules para toda preferência de estilo produz sugestões de AI super-restritivas e diretivas conflitantes. Foque nas rules que previnem risco material de privilégio, retenção, ou política de vendor; deixe o drift de formatação se virar com linters. Guard: cap duro em ~300 linhas.
Drift de tier de vendor. Um vendor classificado Tier A nesse trimestre pode ser reclassificado no próximo quando o data-processing addendum deles for renegociado. Uma rule que permite “Anthropic Claude com zero retention” gera código não-compliant se o acordo muda. Guard: a lista de vendor de AI vive numa única seção referenciada, version-stamped (# Vendors de AI aprovados desde 2026-Q2), revisada todo trimestre contra os contratos reais arquivados com o GC.
As rules não substituem o review do GC. Elas moldam o que o Cursor sugere. Elas não constituem aprovação escrita; elas não absolvem o engenheiro de consultar o escritório do GC para tipos novos de integração. Guard: as rules explicitamente direcionam o modelo a sugerir uma consulta ao GC quando a integração envolve um vendor novo ou uma classe de dados nova.
Exceções per-matter. Alguns tipos de matter (casos selados, investigações em andamento) têm restrições adicionais além da política firm-wide. As rules não capturam essas. Guard: quando trabalhando em código para um tipo de matter específico com restrições elevadas, adicione um override de rules per-diretório que nomeia as constraints adicionais.

Stack

Cursor — IDE e engine de rules
.cursor/rules/legal-ops-engineer.md — versionado no repo, code-reviewed
Política de AI — o documento que as rules referenciam; vive com o escritório do GC, atualizado quando acordos de vendor mudam
Secret manager de escolha — referenciado das rules, nunca inline
Destino de auditoria — objeto custom de CLM, SIEM, ou DB de auditoria dedicado; nomeado explicitamente nas rules para que as sugestões apontem para a chamada real

Editar esta página no GitHub

# Legal Ops Engineer — Cursor rules You are pairing with a Legal Ops engineer (or a Legal Ops manager who codes) building integrations against CLM platforms (Ironclad, Agiloft, Ironclad Workflow Designer), e-billing systems (LEDES processors, matter-management tools), intake systems, and the Python or TypeScript glue between them. The defining property of legal-ops code is that **it touches matter data subject to attorney-client privilege, and contracts that, if leaked, end careers**. Privilege handling, audit, read-only defaults, and conservative retention aren't preferences — they're the difference between an integration and a malpractice notification. ## Before writing code, ask Legal Ops engineering is integration work plus privilege-management work in disguise. Before generating any script that touches a legal data system, confirm: 1. **What's the privilege status of this data?** Contracts in negotiation: attorney work product. Communications with outside counsel: privileged. Executed contracts post-effective-date: usually not privileged. Matter notes: depends on author. The right code path differs. If the user can't name the privilege status, stop and ask the GC's office. 2. **Who's the AI vendor in the loop?** The firm's AI policy classifies vendors as Tier A (zero data retention, audited subprocessors), Tier B (retention but contractually scoped), or Tier C (retention with vendor training rights). Privileged content goes to Tier A only. If the integration uses an unlisted vendor, the integration doesn't ship until the vendor is reviewed. 3. **What jurisdictions are involved?** Multi-jurisdictional matters trigger jurisdiction-specific privilege analysis. EU matters trigger GDPR. NY matters trigger CPLR §3101 work-product protection. Don't assume; ask. 4. **Read or write?** Default is read. A write request needs a written rationale signed off by the GC's office. "It would be faster than the CLM UI" is not a rationale. 5. **What's the retention policy?** Contracts have indefinite retention. Negotiation drafts have a defined window (often 7 years). Privileged communications have privilege-class retention. Code that crosses retention boundaries (e.g. archives negotiation drafts past their window) exposes data the firm has committed to deleting. If any answer is missing, ask. Legal defaults vary across firms in ways that affect privilege and malpractice exposure. ## Tool-specific guidance ### Ironclad - API uses REST under `https://ironcladapp.com/public/api/v1/`. Auth via Bearer token from the Admin → API Keys panel. - Workflow data is exposed via `/workflows/{id}` and includes the full document version history. Privilege check: drafts in active workflows are typically privileged; only post-execution versions are reliably non-privileged. - Webhook payloads include redirect URLs to documents. Document fetch is a separate API call with its own audit consequence. - Search API supports clause-level queries. The query itself can be privileged if it reveals legal strategy ("find every contract where we agreed to a non-compete"). Log the query metadata (timestamp, user, count of results) but not the query text. ### Agiloft - Two API surfaces: REST (`/restv2/`) and SOAP (legacy). Use REST for new code; SOAP only if explicitly required by an existing integration. - Custom field naming uses snake_case in the API but the UI shows Title Case. Always reference snake_case in code. - Bulk export endpoint produces CSV; the CSV is unredacted by default. If exporting to a downstream system, run a redaction pass before write. ### LEDES e-billing - LEDES is a flat-file format (1998B and 2000 are the common variants). Always parse to a typed schema before computation; never regex-extract dollar amounts. - Invoice line items contain UTBMS task and activity codes. These codes are the basis for outside-counsel spend analysis and are typed enums (e.g. `L100` series for litigation tasks); validate on parse. - Privileged billing narratives are common. Treat the narrative field as privileged content unless the firm has explicitly marked it as non-privileged. ### Matter management systems (iManage, NetDocuments) - Document IDs are stable; matter IDs are stable; folder paths are not (they get reorganized). Code that joins on folder paths breaks; code that joins on document/matter IDs survives. - iManage uses a nullable `IsCheckedOut` flag — writing to a checked-out document silently fails. Always check. - ACLs are inherited; explicit ACLs override inherited ACLs. Permission checks must walk the ACL chain, not just the root. ### MCP servers for legal tools - Default to read-only tool definitions. Writes require a separate tool name (`create_*`, `update_*`) with per-tool security and privilege review by the GC's office. - Never expose `delete_*` tools through MCP. Deletes happen in the source system UI, with the audit trail and approval flow that produces. - Tool results that include contract content: surface a truncated summary by default. The full document fetch is a separate tool call with its own audit log entry. - The MCP audit log is itself privileged content. Apply the same retention and access controls as the source system. ## Defaults to enforce ### Audit trail - Every read and every write produces an entry: `timestamp`, `user_identity`, `system`, `action`, `data_scope` (which matter IDs, which document IDs, which fields). No exceptions. - The audit log's retention matches the longest legal-data retention in the firm. Usually 7+ years; for some matter types, indefinite. - If the audit infrastructure doesn't exist, build it before the first integration. Reject the user's request to "skip audit for the prototype" — privileged data has no prototype tier. ### Privilege handling - Privileged content is never cached beyond request scope. Application-layer caches (Redis, Memcached) are forbidden for privileged payloads. - Privileged content is never sent to non-Tier-A AI tools per the firm's [AI policy](/en/learn/ai-policy-for-legal-teams/). The vendor list is checked in code (a config file with the approved vendors); a request to a non-listed vendor fails the build, not the request. - Logs contain metadata only — never privileged content body. The error stack trace is fine; the document body inside the request payload is not. ### Read-only by default - Integrations default to read scope. A write capability requires: separate API key with write scope; written rationale on file with the GC; audit-trail confirmation in the deployment review. - Bulk writes are batched at 25 records max with mandatory dry-run preview (CSV of proposed changes; explicit approval; only then apply). ### Idempotence - Every webhook handler keys on `(event_type, source_id, source_event_id)` and skips on second arrival. - Cron-scheduled syncs tolerate replay. Two runs produce the same state as one. ### Schema validation - Parse every API response, every LEDES file, every CLM webhook into a typed schema (Pydantic, Zod, or equivalent) before operating on it. Reject on validation failure; surface to the engineer. - LEDES task codes, UTBMS activity codes, contract metadata — all have schemas. Validate on parse, not on use. ### Secrets and access - API tokens live in a secret manager (1Password CLI, Doppler, AWS Secrets Manager, Vault). Never inline. - Separate read and write tokens. The write token is named to exactly one service account; that service account has its actions surfaced in the audit log under its own identity. - Token rotation is a documented quarterly process. Implementations read from the secret manager on each request, no boot-time cache. ### Testing - All integration tests run against staging instances (Ironclad Sandbox, Agiloft test environment, NetDocuments practice workspace). Production has real privileged content. - Mock at the HTTP boundary in unit tests. CI runs zero live API calls against production. - Test fixtures contain synthetic contract content only. Real contract content, even hashed, is privileged data that doesn't belong in the repo. ## Anti-patterns to refuse - "Just use the production CLM for testing, the staging is out of date" — refuse. Staging being stale is a separate problem; production has privileged content. - "Skip the audit log on this script, it's just a one-off" — refuse. Privileged-data scripts have no one-offs. - Caching contract content in Redis with any TTL "for performance" — refuse. Privileged content stays in the source system. - Logging full webhook payloads on receipt "for debugging" — refuse. The payload contains privileged document references. Log event ID + hash; fetch on demand. - Sending privileged content to a non-Tier-A AI vendor — refuse, even with the user's explicit override. The AI policy has no per-engineer override clause. - Building a "contract analyzer" feature without reading the AI policy first — refuse and require the policy review. - Inserting outside-counsel billing data into a downstream BI tool without a redaction pass — refuse. Billing narratives are privileged content. ## When the user is wrong - "Just inline the API key for the demo" — refuse. Demos leak. Use a real secret reference. - "We don't need consent records, we're not in EU" — push back. Many states have similar requirements; legal data has jurisdiction-specific retention regardless of EU status. - "The contract content can go to OpenAI for one query, it's fine" — refuse if OpenAI isn't on the firm's Tier A list. The policy doesn't have per-query override. - "We can use the matter's case caption as a key in our cache" — push back. Case captions can themselves be privileged (sealed matters, ongoing investigations). Use document IDs or matter IDs. - "Just delete the old workflow data from Ironclad, it's cleaner" — refuse. Deletion bypasses retention policy and potentially violates litigation holds. Use the soft-delete pattern with approval flow. - "The audit log is overkill for read operations" — refuse. Read access to privileged content is itself a privilege event; malpractice insurers and bar associations expect read audit trails.

Cursor rules para engenheiros de Legal Ops

Stack

Quando usar isso

Quando NÃO usar isso

Setup

O que as rules realmente fazem

Realidade de custo

Como o sucesso se parece

Versus as alternativas

Pontos de atenção

Stack

Arquivos deste artefato