Somewhere between the assessment and the build, your IT lead or your counsel is going to ask who my subprocessors are, where the data sits, how long I keep it, and what happens when we're done. Those answers are on this page rather than three weeks into a questionnaire. Where the honest answer is “I don't do that,” it says so.
Privacy law in the United States is a patchwork. Nineteen-plus states have comprehensive privacy statutes, they don't agree with each other, and new ones arrive every session. Chasing that with a fifty-state matrix produces a document that's out of date the week it's published.
So I don't build to the local minimum. Systems I build are designed to the strictest common denominator — California-level privacy practice, data minimization by default, and disclosure wherever a person is interacting with an AI — regardless of which state your company or your customers sit in. A company operating only in Texas gets the same handling as one selling into California, because your customer list usually crosses state lines whether or not your offices do, and because building two standards means eventually applying the wrong one.
That's a design commitment about how I build, not a certification. I'm a one-person engineering practice, not a compliance department — which cuts both ways. There's no offshore team and no staff turnover to manage in your access review, and there's also no SOC 2 report to hand you. Everything below is written to be independently checkable rather than taken on faith.
What an engagement actually touches, across the assessment, the build, and ongoing operations. Engagement-specific data is scoped in writing before anything connects — this is the baseline.
| Data | Why it exists | Where it lives | Retention |
|---|---|---|---|
| Assessment materialinterview notes, process maps | The raw input to your findings and roadmap report | My workstation, encryptedfull-disk encryption | Deleted 90 days after report deliverymanual — calendar-tracked, not automated |
| Business documentsinvoices, tickets, contracts, forms | The material the automation reads and processes | Your systems wherever the architecture allowsclient-controlled by default | Per engagement scope, in writing |
| Extracted recordsstructured output of a pipeline | The deliverable — what gets written into your system of record | Your systems of record | Yours — governed by your retention policy, not mine |
| Verification logsclaims, checks, verdicts, timestamps | The audit trail behind every monthly accuracy report | Engagement infrastructure, US region | 13 monthsscheduled purge, verified |
| Operational telemetryvolumes, error rates, latency | Monitoring and degradation alerting | Engagement infrastructure, US region | 13 monthsscheduled purge, verified |
| Credentials & accessAPI keys, service accounts | Connecting your systems to the automation | Secret manager — never in code, documents, or chat | Revoked by you at engagement end |
| Inquiry form submissionsthis website | Responding to you before an engagement exists | Supabase, US region | 24 monthsscheduled purge, verified |
Every AI system is a chain of vendors, and your review will need the list. Here's the baseline — what each one sees, and where their terms live so your counsel can read them without asking me first.
| Provider | Role | What it sees | Terms |
|---|---|---|---|
| Supabase | Database of record | Verification logs, telemetry, inquiry submissions | privacy |
| Vercel | Web & API hosting | Request metadata, form submissions in transit | privacy |
| Anthropic | Language model | Conversation and document text at inference time | privacy |
| Stripe | Payments | Billing details — card data never reaches my systems | privacy |
Not aspirations. These are in the running systems today, and they're the same practices the reliability standard is built on — a control nobody verifies isn't a control.
The rules that apply specifically because there's an AI involved — several of which are becoming law and most of which should have been table stakes anyway.
Where a system I build interacts directly with a person — your customer, your vendor, or your own staff — they're told they're dealing with an AI, in plain language, at the start. No pretending to be a person, no ambiguous naming designed to blur the line.
This is increasingly a legal requirement rather than a courtesy, and it's cheaper to build in than to retrofit when your state's disclosure law takes effect. Internal-only automation that processes documents without interacting with a person doesn't need this, and I won't pretend otherwise to pad a compliance story.
Systems I build don't make consequential decisions about people. No automated screening or ranking of applicants or employees. No creditworthiness or eligibility scoring. No automated denial of service to anyone. If a prospective engagement requires it, that's a scope I decline rather than one I improvise.
Where an AI system produces an output that affects a person, a human reviews it before it takes effect. Low-confidence outputs route to a person by design, not by exception.
Client data is not used to train models, is not sold, is not shared with other clients, and is not used to build anything I market to someone else. Model providers are used under commercial terms that exclude training on submitted content.
Automated outbound contact — customer notifications, collections follow-up, renewal outreach — is built against do-not-call and anti-spam requirements: accurate sender identification, honored unsubscribes, and consent tracking where marketing contact is involved. AI-generated voice on an outbound call carries additional federal restrictions, and that constraint goes in the design, not the disclaimer.
If a proposed system's economics depend on ignoring those rules, that's a finding in the assessment rather than a surprise after the invoice.
Email byron@walkeraisystems.com with what you want. Deletion and export requests are acknowledged within two business days and completed within thirty days. You get written confirmation of what was actually removed — not a promise that it was handled. Same address for security questionnaires, DPA review, and anything your counsel needs before an engagement starts.
Make a data requestWhat I design around depending on your sector. Find yours — and if the constraint that matters most to you isn't listed, that's a good question to open the assessment with.
Usually the lightest regulatory load and the heaviest integration debt — which is where the actual risk lives.
The federal definition of “financial institution” reaches well past banks — lenders, mortgage brokers, insurance agencies, advisors, collection agencies, and auto dealers are frequently covered. That brings a written information security program requirement that flows down to service providers like me.
Say so early. It changes the shape of the engagement and it's far cheaper to design for than to retrofit.
Back-office and field-operations automation is well within scope. Control systems are not.
Confidentiality obligations here are usually stricter than any privacy statute, and they're yours to satisfy — my job is not to create a problem for them.
I do not currently sign business associate agreements and I do not handle protected health information. That's a deliberate limit, stated plainly. A one-person practice without a formal compliance program has no business claiming otherwise, and a vendor who'd sign that BAA without hesitating is telling you something.
Administrative work that never touches patient data can still be in scope — vendor invoicing, supply chain, credentialing logistics, internal reporting. That gets scoped carefully and in writing, with the boundary made explicit, or it doesn't happen.
If the project needs PHI, the honest answer is to hire someone else, and I'll say so in the first conversation rather than the third.
Regardless of sector, automation that touches hiring, performance, scheduling, or termination sits in the fastest-moving area of AI regulation right now — several states and cities now require bias audits or disclosure for automated employment decision tools.
A compliance page that only lists strengths isn't a compliance page, it's marketing. Here's the other half.
If your project needs something on this list, the right answer is a vendor who's built for it — and I'd rather tell you that in the first conversation than discover it in month three.
Systems verify their own work against the source of truth rather than trusting self-reports. Drift and schema changes are monitored, not assumed away. The reliability page demonstrates the mechanism.
If data you're responsible for is exposed, you're notified in writing without delay — with what's known, what isn't yet known, and what's being done. No waiting until the picture is flattering.
Cause, scope, timeline, and the change that prevents recurrence. On operate-and-maintain engagements it lands in the monthly report whether or not you noticed the incident.
This page describes engineering and operational practice at Walker AI Systems. It is not legal advice, not a warranty, and not a certification. Regulatory requirements vary by state, industry, and circumstance, and several of the AI-specific laws referenced here are new or not yet in force. Your obligations are yours to confirm with your own counsel.
Binding terms for any engagement live in the engagement agreement and its data processing terms — not on a web page. Where this page and a signed agreement differ, the agreement governs.
Found something here that's wrong, stale, or overstated? Tell me and I'll correct it: byron@walkeraisystems.com.
LAST REVIEWED · July 2026
Ask who their subprocessors are, where your documents are processed, how long they retain what they extract, and what happens to all of it if you cancel. If that answer takes three weeks and arrives from an account manager, you've learned something. Every assessment I run asks those same questions about the systems you already have running.
Start an Assessment