Security review, data-handling design, vendor diligence, and a governance model for the AI you have shipped or are about to.
Every AI feature you ship adds attack surface. Prompt injection, training-data exfiltration, vendor data leakage, secrets in prompts, hallucinated actions that touch real systems. Most teams shipped the AI before they wrote the rules for handling it. Some shipped it before they read the vendor's data-handling policy.
Boards and auditors are starting to ask. Regulators are about to. NIST AI RMF, EU AI Act, ISO 42001, sector-specific rules in finance and healthcare. The honest answer for most mid-market companies right now is 'we have not looked at this.' That answer stops working soon.
AI security is not a feature you bolt on. It is how you build.
We audit what you have shipped, design how it should handle data going forward, run vendor diligence on the AI tools your teams are actually using, and land a governance model your security and legal leads can defend.
Your AI vendor's marketing page says 'enterprise-grade security.' You assume that covers you. It does not. You are responsible for the prompts you send, the data you ground the model on, the actions you let the model take, and the audit trail. Vendor security is a precondition, not a substitute.
Half your team is pasting customer data into ChatGPT. Your CFO does not know. Your CISO does not know. Your data-residency contract with your largest customer says they cannot. Until you audit usage, you cannot govern it.
You stood up an AI committee. It meets monthly. There is no written data-handling standard, no approved-vendor list, no incident playbook. The committee is a meeting, not a governance system.
An AI footprint audit: every AI tool in production or in use, what data each one touches, what permissions each one has, what the vendor's actual data-handling policy says, and where the gaps are. The unsexy work of just knowing what you have.
A data-handling architecture for AI workflows: what classes of data can go to which model, what has to stay on-prem or in your tenant, what gets redacted before a prompt, how outputs get logged and reviewed. A real spec, not a poster.
A vendor-diligence pack for your top five AI tools: data-residency, sub-processors, DPA terms, training-on-prompts settings, retention windows, audit-log capability. The questions your procurement team should have asked at purchase.
A governance model: a written acceptable-use policy, an approved-tool list with rationale, an incident response runbook tuned for AI incidents (prompt injection, vendor breach, hallucinated action), an executive-review cadence.
A 60-day remediation plan ranked by exposure. The two or three things to fix first, with owners, dates, and what 'done' looks like.
A four-week fixed-fee engagement. Week 1 is footprint audit (what AI is running, what data it touches, what vendors are in scope) and stakeholder interviews with security, legal, IT, and the business owners who shipped each tool. Week 2 is the data-handling architecture and vendor-diligence pack. Week 3 lands the governance model: acceptable-use policy, approved-vendor list, incident playbook. Week 4 produces the 60-day remediation plan and runs a working session with security, legal, and executive sponsors to align on owners and dates.
For companies with formal compliance frameworks in scope (SOC 2, ISO 42001, NIST AI RMF, HIPAA, EU AI Act readiness), the deliverables are mapped to the relevant control families so your auditors and customers can read them directly.
The system that's been on the roadmap for two years. The migration that's already failed once. The AI strategy that didn't make it past the deck. That's the one we want.
Loading search...
