Privacy and data handling
This page explains how information should be handled during the public audit request, roadmap work, and custom AI implementation. It is intentionally practical: do not send sensitive production data until the project has a scoped handling plan.
Public-form boundary
The Systems Audit form is for project context and fit review. Share enough detail to evaluate the workflow, but do not include credentials, private keys, regulated records, or raw confidential datasets in the public form.
Audit request intake
The Systems Audit form collects the information you submit: contact details, company or project context, workflow bottlenecks, data sources, timeline, security requirements, and budget range.
Used to evaluate fit and decide whether a Phase 1 Roadmap makes sense.
Not a payment form and not a production data upload flow.
Do not submit passwords, secrets, regulated records, or confidential datasets through the public form.
Project data
If an engagement moves forward, project data handling is scoped in the roadmap and implementation plan. Different projects can require different cloud, local, or hybrid deployment patterns.
Data access should be limited to what is needed for the scoped workflow.
Sensitive sources, retention limits, and access controls should be identified before build work.
Client data is not repurposed by me for model training.
Third-party processing
Some builds may involve model providers, hosting vendors, databases, APIs, or automation services. Those choices are implementation decisions, not assumptions made before scoping.
Provider, retention, and data residency requirements should be raised during audit or roadmap work.
Local or hybrid patterns can be evaluated when cloud processing is not acceptable.
Vendor-specific constraints should be documented before production deployment.
Ownership
The engagement model is built around buyer-owned deliverables. Code, documentation, architecture notes, and scoped data artifacts belong to the client unless a written agreement says otherwise.
No proprietary platform lock-in is required by the engagement model.
Phase 1 deliverables remain useful even if you decide not to continue to Phase 2.
Production ownership and operational responsibilities should be explicit before launch.
Data boundaries are part of scope.
A serious AI build needs explicit boundaries around source data, model providers, access, retention, review states, and deployment. If those boundaries are unclear, Phase 1 should clarify them before Phase 2 is priced.
Use the public audit form for fit context, not secrets or raw production data.
Flag security, compliance, residency, or vendor restrictions early.
Treat Phase 1 as the place to define what data is needed and how it should be handled.
Do not approve a larger build until deployment and data boundaries are written down.
Need security context too?
Privacy covers intake and data-handling expectations. Security covers compliance posture, questionnaires, deployment options, and buyer qualification. About explains the operating model behind the engagement.