Design the system. Own the pattern. Make it reusable.
Your job: design it right the first time so it scales to 100 clients. Sales will land the deal. Delivery will build it. You own the architecture, the technical decisions, the reusable patterns. Here's what great SA work looks like.
What you own.
You are the architect. Your design is the foundation for delivery at scale. Every decision you make either enables reuse or forces rework. Your success metric: Client A's architecture is 80% reusable for Client B.
The imperative: Make every design decision intentional. No "good enough." No "we'll figure it out in implementation." No reinventing the wheel for Client 2. Your job is to design once, build many times.
How we'll map the AI estate.
Before Delivery starts, you design how discovery runs. What tools? What data sources? What access do we need? You own technical scoping so Delivery doesn't waste time guessing.
Your design questions
- What's their cloud (AWS/Azure/GCP/hybrid/on-prem)?
- Do they have Nexthink AI-DRIVE already? If so, we reuse its telemetry.
- What AI models are they running (Copilot, ChatGPT, custom)?
- What's the access level (root? read-only? firewall constraints)?
- How much data history (last 30 days? 6 months?)?
You produce (for Delivery)
- A 1-page discovery architecture (tools, data sources, queries).
- A list of cloud IAM roles / credentials needed.
- A data-access checklist (API keys, SSH access, log trails, etc.).
- An estimated data volume (how many assets, models, logs).
Reusability win: Once you've designed discovery for AWS + Nexthink + Copilot, the next client with the same stack is 40% faster. Document your decisions.
The control library. The scoring logic.
You curate the control library (which standards matter?), design the scoring methodology (how do we map findings to controls?), and produce the assessment readout template (how do we present risk?).
Your design decisions
- Standard selection: NIST AI RMF? ISO 42001? EU AI Act? Industry-specific (health/finance)? This depends on the client's risk profile.
- Control-to-finding mapping: How do we link "this app is using unapproved Copilot" to "you fail the model approval control"?
- Severity scoring: What's a CRITICAL vs. HIGH vs. MEDIUM? (This differs by industry.)
- Coverage targets: What % of assets/models do we assess? (100%? 80%?)
You produce (for Delivery)
- A control library (Excel or CSV: control ID, standard, description, severity if failed).
- A scoring rubric (how to evaluate each control: pass/partial/fail).
- A findings template (control ID, asset, evidence, severity, remediation).
- A readout deck template (posture score, findings by severity, "what's next").
Reusability win: Your control library + scoring rubric for "regulated fintech" becomes the template for the next fintech client. Documentation = compounding leverage.
The platform architecture.
You design the control registry, the intake workflows, the monitoring layer, and the dashboard. Delivery will code it. You own that the design is clean, extensible, and repeatable.
Core design choices you make
- Registry schema: How do we model a "control"? (fields, relationships, state machine)
- Intake workflow: How does a new AI model flow through approval? (Step 1: submit → Step 2: classify risk → Step 3: route to owner → Step 4: approve/reject)
- Monitoring agents: What drift do we watch for? (Unapproved tool in use again? Control not enforced? New shadow AI?)
- Dashboard lenses: Operational view vs. strategic view vs. analyst deep-dive. Different audiences, same data.
- Tech stack: PostgreSQL or Cosmos? Node.js or Go? Lambda or Fargate? These decisions shape reusability across clients.
You produce (for Delivery)
- An architecture diagram (registry ← → intake engine ← → monitoring ← → dashboard).
- A data model (Postgres schema, API endpoints).
- A state machine for the intake workflow (all states, transitions, escalations).
- A monitoring spec (what each agent watches for, alert rules).
- A dashboard wireframe (layout, views, interactions).
Design constraints to enforce
- No client lock-in: The system must run on-prem or any cloud (not AWS-only).
- Stateless services: Registry is the DB. Everything else is disposable.
- Audit trail: Every decision is immutable + timestamped.
- Extensible: New control types, new monitoring agents, new dashboard views without core changes.
Reusability win: Your registry schema + intake state machine work for a healthcare client, a fintech client, and a real-estate client. Design for the 100th case, not the first.
How the client runs it forever.
The system goes live. Who monitors it? Who fixes it? Who updates the control library when NIST changes? You design the ops model so Delivery can hand it off and the client can maintain it.
Your design specs
- Monitoring: What metrics matter? (Agent uptime, API latency, alert noise?)
- Runbooks: If X fails, here's what to do. (Error recovery, re-monitoring, escalation.)
- Standards updates: When NIST publishes new guidance, how do we evolve the control library? (Automated script? Manual review?)
- Performance targets: Dashboard < 2s load time? Registry API < 100ms? You set the SLOs.
You produce (for Delivery + client)
- An ops runbook (troubleshooting, escalation, maintenance cadence).
- A monitoring spec (metrics, alerts, dashboards).
- A standards-update procedure (how to add/change controls).
- Training materials (for the client's ops team to run it solo).
What you sign off on. What Sales / Delivery must do.
| Checkpoint | You (SA) | Sales | Delivery |
|---|---|---|---|
| Pre-kickoff due diligence | Tech audit call, stack assessment, discovery plan | Provided intro, context on customer pain | — |
| Discovery design sign-off | Approves: this design will get 90%+ coverage | — | Reviews: is this buildable? |
| Assessment design sign-off | Approves: control library + scoring are sound | Reviews: will the readout close Phase 2? | Reviews: do I have what I need to score? |
| Implementation design sign-off | Approves: architecture is clean, extensible, tested | — | Codes from the design |
| Go-live readiness | Signs off: design is implemented correctly | Is the client ready to take ownership? | System is production-ready; training done |
| Operations handoff | Approves: ops runbook is complete + client trained | — | Trains client team, hands off the system |
Legend: R = Responsible (does the work) · A = Accountable (signs off) · C = Consulted (input) · I = Informed (kept in loop)
Design for the 100th client, not the 1st.
Every design choice should ask: "Will this work for the next 99 clients?" If the answer is no, redesign it.
What stays the same across clients
- Registry schema (control model).
- Intake state machine (approval workflow).
- Monitoring architecture (agent pattern).
- Dashboard structure (operational / strategic views).
- Ops runbook template.
What changes per client
- Cloud provider (AWS vs. Azure).
- Control library (NIST vs. ISO vs. industry-specific).
- Severity thresholds (fintech != healthcare).
- Integration points (Nexthink? Datadog? ServiceNow?).
- Monitoring scope (all models vs. high-risk only?).
Measure this: Client B should be 40% faster to design than Client A. Client C should be 40% faster than Client B. If design time isn't dropping, your reusability isn't working.