Privylaw
Secure, attorney-supervised AI for privileged communication.
A matter-scoped platform that keeps AI inside attorney-controlled workflows — context selection, review loops, audit records, and an Amazon Bedrock model path.
Clients were already taking legal questions to public AI tools.
Legal clients want fast answers. Public AI tools make those answers feel instantly available, but they are not designed around attorney supervision, matter context, confidentiality controls, source discipline, or durable audit records.
Privylaw was built around a different premise: if clients want fast AI-assisted help, give them a secure place to ask inside the attorney-controlled matter workflow.
The unit of work was not chat. It was the legal matter.
Every important object in Privylaw belongs to a matter: users, roles, rooms, messages, files, AI interactions, review decisions, audit events, retention state, and legal-hold state.
That boundary lets AI behavior follow the same operating rules as the rest of the product. Privy, the assistant inside Privylaw, operates inside the matter workflow — the server decides what context exists, what the requester can access, and whether the answer can be returned or must be reviewed.
A real product surface, not a prototype wrapper.
- Next.js web app for workspace, matter, thread, review, admin, and settings surfaces.
- Fastify API and WebSocket server for auth, tenancy, messaging, files, AI, notifications, audit, and admin routes.
- BullMQ worker for notifications, retention, export, scan, verification, context ingestion, and async AI processing.
- PostgreSQL tenancy with Row-Level Security, Redis queue/realtime infrastructure, and shared TypeScript contracts.
- Deployment, migration, encryption, retention, eDiscovery, and cloud-readiness runbooks.
The matter boundary shaped the product and the AI.
Privylaw was designed around tenant and matter boundaries from the beginning. That let AI behavior sit on top of the same access model as messaging, files, notifications, audit, and administration instead of becoming a separate ungoverned tool.
- Application requests establish tenant and user context before tenant-scoped work runs.
- Role-aware routes control access to matter, room, message, file, workspace, and admin surfaces.
- Authentication, CSRF protection, production startup checks, and unsafe-configuration guards were part of the build.
- Encryption paths, KMS-ready key wrapping, retention, legal hold, audit events, and guarded migration runbooks were treated as product requirements.
The hard part was not calling a model.
Amazon Bedrock was integrated as a controlled model provider inside a larger product system. The API kept orchestration, retrieval, policy enforcement, audit, and persistence in the application boundary while Bedrock handled the model runtime.
That provider layer matters because product behavior is not shaped by raw model output alone. It is shaped by context assembly, review policy, trace metadata, token budgets, output limits, and usage guardrails.
Human judgment stayed in the product, not outside it.
Client-visible AI responses can be held for attorney review before they are delivered. Internal-only interactions can follow different routing rules — the product supports both speed for the legal team and supervision for client-facing output.
Privylaw does not ask firms to trust a model by itself. It keeps professional judgment in the loop and makes that review path visible in the system.
The system records what the model had, and what it did not.
AI interactions can include selected file IDs, recent conversation context, matter metadata, jurisdiction or firm guidance, and structured context logs. When selected files are missing, unavailable, excluded, or pruned by budget, the system preserves those reasons as context metadata.
That makes the final answer inspectable: what context was available, what evidence was missing, whether policy required review, and whether the response relied on retrieved evidence, inference, or both.
Known production patterns, used to keep the AI workflow bounded.
- Users
- Attorney, staff, client
- Web app
- Next.js workspace and matter UI
- API layer
- Fastify routes and WebSocket server
- Data boundary
- PostgreSQL tenancy with Row-Level Security
- Async work
- Redis, BullMQ, notifications, scans, AI jobs
- Model path
- Amazon Bedrock through a Qwen provider layer
138
SQL migration files
123
API smoke-test files
44
tracked runbook files
The work moved from matter model to cloud readiness.
- Week 1Scope the system around tenants, users, roles, matters, rooms, messages, files, and audit events.
- Week 2Build the collaboration surface: rooms, invitations, realtime behavior, file lifecycle, workspace screens, and matter navigation.
- Week 3Add Privy inside the matter context, including bounded context assembly, selected-file handling, source metadata, and review routing.
- Week 4Harden authentication, tenancy, encryption, retention, legal hold, audit, admin policy, and operational controls.
- Week 5Integrate the Qwen path through Amazon Bedrock and prepare AWS deployment, ECS packaging, guarded migrations, and cloud readiness.
- Week 6Stabilize deploy blockers, mobile behavior, context edge cases, missing-source handling, smoke coverage, and readiness checks.
A repeatable pattern for serious AI workflows.
Privylaw demonstrates the kind of AI work sammartin.ai is built for: document-heavy review, expert approval loops, sensitive data, multi-system workflows, operational monitoring, and AI that must be useful without being uncontrolled.
This is a software and product case study. It is not legal advice and does not claim that any software system guarantees attorney-client privilege, compliance, or legal outcomes.