Un archivo .cursorrules de Cursor afinado para el ingeniero de Legal Ops in-house (o el manager de Legal Ops que codea): construir configuraciones de CLM, escribir MCP servers para herramientas de IA legal, automatizar intake e integrar Ironclad, Agiloft, e-billing y sistemas de matter-management. El artefacto es un archivo — apps/web/public/artifacts/cursor-rules-legal-ops-engineer/.cursorrules — que colocas en el directorio .cursor/rules/ de tu proyecto.

La propiedad definitoria del código de legal-ops es que toca data de matters sujeta a privilegio attorney-client, y contratos que, si se filtran, terminan carreras. El manejo de privilegio, audit, defaults read-only y retención conservadora no son preferencias — son la diferencia entre una integración y una notificación de mala praxis. Las rules en este bundle codifican la postura de privilegio de la firma para que el asistente de IA de Cursor no sugiera el tipo de código que termina en una audiencia disciplinaria del colegio.

Cuándo usar esto

Eres un ingeniero de Legal Ops, manager de Legal Ops que escribe código, o un ingeniero legal-tech (típicamente Python o TypeScript) construyendo integraciones contra un CLM, sistema de e-billing o herramienta de matter-management. Tu firma tiene al menos un abogado in-house que firma decisiones de vendor de IA. Cursor es tu IDE.

Cuándo NO usar esto

Eres un vendor SaaS de legal-tech construyendo producto para law firms. Las rules están afinadas para el lado consumidor — el equipo in-house que vive con exposición a privilegio para siempre — y asumen restricciones jurisdiccionales/de política de IA que son distintas en la ingeniería de producto del lado vendor.
Eres un paralegal automatizando tareas recurrentes vía workflows de CLM o herramientas no-code. Las rules asumen code reviews, control de versiones y un pipeline de despliegue; un operador de workflow no-code no se beneficia.
Tu firma no tiene política de IA ni oficina de GC para consultar. Las rules referencian “vendors de IA Tier A” repetidamente — sin una política que defina tiers, la restricción más load-bearing no es operativa. Consigue la política escrita primero.

Setup

Copia el artefacto. Toma .cursorrules del bundle de arriba (o descarga el zip) y colócalo en el directorio .cursor/rules/ de tu proyecto. El indicador de Project Rules de Cursor confirma que está cargado.
Ajusta la lista de vendors de IA. Las rules referencian “vendors Tier A” genéricamente. Edita la sección de manejo de privilegio para nombrar los vendors Tier A reales aprobados por tu firma (ej., Anthropic Claude con acuerdo de zero-retention, Microsoft Azure OpenAI bajo BAA). Sin esto, las sugerencias se quedan genéricas.
Setea el destino del audit. Las rules requieren que cada read y write produzca una entrada de audit, pero no dictan dónde. Edita la sección “Audit trail” para apuntar a tu destino de audit (un objeto custom de CLM, un SIEM, una database de privileged-access). Las rules referencian el destino por nombre en sugerencias.
Setea el secret manager. Las rules prohíben credenciales inline y dirigen al modelo hacia tu secret manager de elección (1Password CLI, Doppler, AWS Secrets Manager, Vault). Elige uno y edita la sección “Secrets and access”.
Testéalo en una task representativa. Pídele a Cursor: “escribe un script de Python que lea contratos desde Ironclad con un tag particular, resuma sus términos de renovación con Claude y postee un resumen a un matter.” El output debería preguntar qué tier de Claude la firma aprobó, dónde va el audit log, y si los contratos son post-effective-date o están en negociación activa. Si no pregunta, las rules no están cargadas — checkea el indicador.

Qué hacen realmente las rules

El bundle está estructurado como cinco capas, aplicadas a cada prompt de Cursor:

Un preámbulo “antes de escribir código, pregunta”. Cinco preguntas que Cursor saca a la luz antes de generar: estado de privilegio de la data, tier del vendor de IA en la política de la firma, jurisdicciones involucradas, read-vs-write, política de retención. Estas mapean directamente a las preguntas que la oficina de un GC haría en una reunión de revisión de vendor — preventivamente.
Guidance específica por tool para Ironclad (endpoints REST, privilegio en versiones de workflow, logging de metadata de search-query), Agiloft (REST vs SOAP, snake_case, redacción en bulk export), LEDES (schemas 1998B/2000, códigos UTBMS, privilegio de billing-narrative), sistemas de matter-management (IsCheckedOut de iManage, herencia de ACL) y MCP servers para herramientas legales (defaults read-only, sin exposición de delete_*, audit-log-as-privileged-content).
Defaults a enforzar sobre audit, manejo de privilegio, read-only-by-default, idempotencia, validación de schema, secretos y testing. Cada default es concreto: el audit log retiene 7+ años; el contenido privilegiado está prohibido en caches de aplicación; los bulk writes baten en lotes de 25 records máx con preview de dry-run obligatorio.
Anti-patrones a rechazar. Patrones específicos que el modelo rechaza: ambiente de producción-como-test, saltar audit “para el prototipo,” cachear contenido privilegiado en Redis, mandar contenido privilegiado a vendors no-Tier-A incluso con override del ingeniero.
Una sección “cuando el usuario está equivocado”. Los atajos a los que los ingenieros recurren bajo presión de deadline contra los que el modelo empuja de vuelta. La rule más cost-saving: rehusarse a mandar contenido privilegiado a un vendor de IA no-Tier-A independientemente de cómo el usuario framee el pedido, porque la política de IA explícitamente no tiene cláusula de override per-ingeniero.

Realidad de costos

Costo de tokens: cero. Las rules de Cursor son contexto local enviado en cada prompt — sin cargo por request. El archivo ocupa 5-6 KB de contexto.
Tiempo de setup: ~15 minutos para colocar el archivo y configurar la lista de vendors, destino de audit y secret manager.
Overhead por task: el preámbulo agrega 1-2 turnos de diálogo. Para una task de 30 minutos, esto es ruido; para un throwaway de 5 minutos, es pesado. Los throwaways que involucran contenido privilegiado no deberían existir.
Mantenimiento: ~1 hora por trimestre para revisar el archivo. Las clasificaciones de tier de vendor cambian cuando los contratos se renuevan; las rules jurisdiccionales evolucionan (las fechas de cumplimiento del EU AI Act aterrizaron en 2025-26, con enforcement por fases); las versiones de SDK de CLM derivan. La revisión trimestral con la oficina del GC mantiene las rules precisas.

Cómo se ve el éxito

El código que viola privilegio nunca entra a review. Las rules sacan a la luz el check de privilegio antes de la generación, así la primera versión del script ya referencia el tier de vendor correcto y el call correcto al audit log.
Las reuniones de revisión de vendor se acortan. Cuando el ingeniero llega a la oficina del GC para una revisión de nueva integración, la implementación ya referencia la política de IA explícitamente; la conversación es “¿esto cumple la política?” no “explica qué construiste.”
Las auditorías del colegio/aseguradora sacan a la luz un trail limpio. Cada read y write de contenido privilegiado tiene una entrada de audit. La revisión anual de la aseguradora de mala praxis recorre el objeto de audit, no la memoria del ingeniero.
Los nuevos ingenieros de legal-ops hacen ramp-up más rápido. Leer .cursor/rules/legal-ops-engineer.md una vez enseña la postura de privilegio de la firma; el nuevo ingeniero no tiene que absorber un trimestre de feedback de code review para entender qué vendors de IA están aprobados y por qué.

Versus las alternativas

Sin rules en absoluto (statu quo). Cursor genera código legal-tech plausible que viola la política de IA en la primera corrida. El costo de un incidente de leak de privilegio es meses de respuesta del colegio de abogados y exposición potencial a responsabilidad profesional.
Un doc de convenciones de codeo del equipo escrito por la oficina del GC. Funcionalmente cerca a sin rules — el doc no se carga al contexto de la IA, así que las sugerencias no lo reflejan. El archivo de rules de Cursor hace al doc operativo en cada prompt.
Una herramienta de cumplimiento de IA del lado vendor (ej., Croct, Harvey para revisión de cumplimiento). Atrapa problemas después de que el código está escrito. Coexiste con las rules de Cursor; las rules previenen la violación, la herramienta de cumplimiento atrapa lo que se cuela.

Watch-outs

Las rules requieren soporte de Project Rules de Cursor. Las versiones más viejas de Cursor no cargan .cursorrules. Verifica en la versión de Cursor que tu equipo usa; el indicador en la parte de abajo del editor confirma que las rules están activas. Guard: incluye un check de una línea en el README de tu proyecto (“Cursor 0.40+; el indicador de rules debe mostrar ‘legal-ops-engineer.md active’”).
No sobre-especifiques. Agregar rules para cada preferencia de estilo produce sugerencias de IA sobre-restrictivas y directivas conflictivas. Enfócate en las rules que previenen riesgo material de privilegio, retención o política de vendor; deja que el drift de formato lo maneje un linter solo. Guard: cap duro en ~300 líneas.
Drift de tier de vendor. Un vendor clasificado Tier A este trimestre puede ser reclasificado el próximo cuando su data-processing addendum se renegocie. Una rule que permite “Anthropic Claude con retención cero” genera código no-cumpliente si el acuerdo cambia. Guard: la lista de vendors de IA vive en una única sección referenciada, version-stamped (# Approved AI vendors as of 2026-Q2), revisada cada trimestre contra los contratos reales en archivo con el GC.
Las rules no reemplazan la revisión del GC. Dan forma a lo que Cursor sugiere. No constituyen una aprobación escrita; no absuelven al ingeniero de consultar a la oficina del GC para nuevos tipos de integración. Guard: las rules dirigen explícitamente al modelo a sugerir una consulta con el GC cuando la integración involucra un nuevo vendor o una nueva clase de data.
Excepciones por matter. Algunos tipos de matter (casos sellados, investigaciones en curso) tienen restricciones adicionales más allá de la política firm-wide. Las rules no capturan esas. Guard: cuando trabajes en código para un tipo de matter específico con restricciones elevadas, agrega un override de rules per-directorio que nombre las restricciones adicionales.

Stack

Cursor — IDE y motor de rules
.cursor/rules/legal-ops-engineer.md — versionado en el repo, code-reviewed
Política de IA — el documento que las rules referencian; vive con la oficina del GC, actualizado cuando los acuerdos de vendor cambian
Secret manager de elección — referenciado desde las rules, nunca inlineado
Destino de audit — objeto custom de CLM, SIEM o DB de audit dedicada; nombrado explícitamente en las rules para que las sugerencias apunten al call real

Editar esta página en 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 ingenieros de Legal Ops

Stack

Cuándo usar esto

Cuándo NO usar esto

Setup

Qué hacen realmente las rules

Realidad de costos

Cómo se ve el éxito

Versus las alternativas

Watch-outs

Stack

Archivos de este artefacto