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.
ENGINEERING PRACTICE · NOT A LEGAL WARRANTY reviewed and dated below
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 material interview notes, process maps | The raw input to your findings and roadmap report | My workstation, encrypted full-disk encryption | Deleted 90 days after report delivery manual, calendar-tracked, not automated |
| Business documents invoices, tickets, contracts, forms | The material the automation reads and processes | Your systems wherever the architecture allows client-controlled by default | Per engagement scope, in writing |
| Extracted records structured 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 logs claims, checks, verdicts, timestamps | The audit trail behind every monthly accuracy report | Engagement infrastructure, US region | 13 months scheduled purge, verified |
| Operational telemetry volumes, error rates, latency | Monitoring and degradation alerting | Engagement infrastructure, US region | 13 months scheduled purge, verified |
| Credentials & access API 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 submissions this website | Responding to you before an engagement exists | Supabase, US region | 24 months scheduled purge, verified |
| Prospect & contact records business contact details, notes, published research | Knowing who I've spoken to and what was said: the sales pipeline | Supabase, US region | No fixed clock deleted on request, or when the record goes cold. See below |
Never stored, in any engagement: payment card numbers · Social Security numbers · bank credentials · government ID numbers · protected health information · biometric identifiers. Where a document pipeline would otherwise encounter one of these, the field is redacted before storage or the document is routed to a human instead. Payments run through Stripe and card data never reaches my systems.
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 |
| BoldSign | Contract signature | The contract itself, plus signer name, email, IP and timestamps on the completion certificate | privacy |
| Namecheap Private Email | Business email | Correspondence with you, and any document attached to it | privacy |
| Resend | Automated email delivery | Notification and digest messages in transit, including names and contact details submitted through the contact form | privacy |
All primary storage is US-region. This is the baseline stack. Your engagement gets its own subprocessor list, because the integrations that matter are yours: your ERP, your CRM, your ticketing system, your document store. That list is written into the engagement documentation before anything connects, and no subprocessor is ever added to a live client system without telling you first. Where your policy rules out a vendor on this list, say so during the assessment. Most of the stack is substitutable if it's known early, and considerably more expensive to swap after the build.
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.
Access
Input handling
Transport & storage
The section above lists controls. This one is how I check they are still true, because the same standard I apply to a system I build for you has to survive being pointed at my own.
Every sweep, four buckets
A full pass over my own repository and infrastructure: secrets exposure, injection surfaces, authentication, prompt injection. Every finding lands in one of four categories, and all four are recorded, not just the flattering ones:
The last two carry the weight. A security review with no accepted risks is one where nobody looked hard, and a review that doesn't name its own blind spots is claiming omniscience.
What you get, and what you don't
I won't publish the audit itself. A live, itemized list of a running system's weaknesses isn't transparency. It's a target list, and any vendor who hands you one is telling you something about their judgment.
What you get instead is concrete: a written answer to your security questionnaire, a walkthrough of the current posture with your security team, and the subprocessor and dependency lists for your engagement. That is on the record in the data processing agreement, not just on this page.
One thing I will say about the last sweep: it produced fixes, not a clean bill of health. A self-audit that finds nothing is a self-audit that wasn't really performed, and I'd rather tell you that than claim a perfect score.
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.
Disclosure
Where a system I build interacts directly with a person, whether that is 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.
Human oversight
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.
Training
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.
Outbound contact
Automated outbound contact, meaning customer notifications, collections follow-up and 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.
You own the deliverable on full payment, and my terms indemnify you against claims that my work product infringes someone else's IP. That is only worth something if I can actually keep it, so license review is a gate on the build, not a formality. It runs before the acceptance session, and the dependency list ships with your handoff documentation.
| License family | Does it ship in your deliverable? |
|---|---|
| Permissive MIT, BSD, Apache-2.0, ISC | Yes. Attribution notices required by the license are carried into your handoff documentation. |
| Copyleft GPL, AGPL, SSPL | Not without your written agreement. If one is genuinely the right tool, you are told in writing what it obligates you to before it goes anywhere near the build, and it is named in the SOW or a change order. |
| Unlicensed or unknown no license file, unclear provenance | Never. It does not ship at all. |
Every third-party package, model, dataset and template embedded in or required by the deliverable is inventoried by name, version and license, generated from the lockfile where one exists, written down by hand where one doesn't. That list goes in your repository and your handoff pack, so a question two years from now has an answer rather than an archaeology project.
The question everyone is now asking
A meaningful amount of what I write is drafted with an LLM. Pretending otherwise would be absurd from a practice that sells AI systems, so here is the actual standard.
Generated code is reviewed and materially modified before delivery, and never committed unread. It is treated as mine to indemnify, to exactly the same standard as code I typed character by character. The provenance of the draft does not change who answers for the result.
What I don't touch
Anything you hand me, whether source, data, documents or templates, remains yours, and the rights and consents in it remain your responsibility. I don't relicense it, don't redistribute it, and don't fold it into anything I build for anyone else.
The reusable methods and tooling I bring to an engagement stay mine, and you get a license to use them in what I deliver. That split is written in the terms rather than left to be discovered at exit.
The honest limit. This is a review by one engineer against the license text and the lockfile. It is not a legal clearance opinion and not a patent search, and I won't describe it as one. It catches what actually bites in practice: copyleft creeping into a deliverable, an unlicensed snippet, a missing attribution notice. If your risk profile needs formal IP clearance, that is outside counsel's job and it should be budgeted as such.
How to exercise any of this
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. Every deletion is verified by re-querying the same records afterwards, because a database's own success report is a self-report, and the confirmation names what was kept too, with the reason.
A data processing agreement already exists. Ask and it comes back the same day, with the processing details, security measures, and your engagement's subprocessor list filled in rather than left as a blank annex. Send yours instead if you'd rather; I'll read it. Same address for security questionnaires and anything else your counsel needs before an engagement starts.
The governing agreements are published in full rather than summarized here: the Terms of Service, covering ownership, the guarantee, liability and indemnity, and the Privacy Policy. Every Statement of Work is written against them, and a dated copy of the Terms as they stood that day is sent in the same envelope as the SOW, so there is never a question about which version you agreed to.
Make a data request ↗What 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.
Two policies, both current, both written in the name of Walker AI Systems LLC. A certificate naming your company as certificate holder is available on request, usually the same day you ask.
01 · Professional liability
$1,000,000 per claim and $1,000,000 aggregate, written by Philadelphia Indemnity Insurance Company (A.M. Best A++, Superior). This is the one that matters here: it responds when the work product itself causes a financial loss, which is the failure mode a systems engagement actually has.
02 · General liability
$1,000,000 each occurrence and $2,000,000 aggregate, including $1,000,000 personal and advertising injury, written by The Hartford (A.M. Best A+, Superior).
Both policies run 27 July 2026 through 27 July 2027. Additional insured and waiver of subrogation endorsements are available where your vendor agreement requires them. Ask before signing, not after.
A compliance page that only lists strengths isn't a compliance page, it's marketing. Here's the other half.
Out of scope · not negotiable
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.
01 · Detect
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, and the receipts show what its absence has cost others.
02 · Notify
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.
03 · Report
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.
04 · Before any of that
Incident response here is a document, not an intention: version 2.0, dated 27 July 2026, reviewed annually and after any incident. It defines what counts as an incident and at what severity. It fixes the order of the first hour, starting with the instruction not to wipe the machine, because repairing the evidence destroys any ability to prove how far the problem did or didn't reach. It orders credential rotation by dependency rather than by panic, with domain and email first, since that is what an attacker uses to reset everything else, with an explicit check for the silent mail-forwarding rule that survives a password change.
It also specifies what evidence is preserved before anything is fixed, what you are told, how fast, and the section most plans leave out entirely: what this practice cannot do on its own at two in the morning.
Ask and I'll email it to you. Most vendors will tell you they have an incident response plan. The useful follow-up question is whether they'll send it to you before you've signed anything.
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 ↗