Local processing, with the boundaries stated

Local processing means that the work we classify as a supported workload runs on computing systems we own, in an environment we administer, with access we control. The homepage describes this under owned infrastructure: direct control over supported deployments, customization, and capacity instead of relying entirely on rented access.

Two things it does not mean. It does not mean your data is never sent anywhere else; ad platforms, analytics, call tracking, CRM, and email delivery still process the data they need to do their jobs. And it does not change ownership. Clients retain ownership of their data; our ownership of the hardware does not change that.

This page states the boundaries so your reviewers can evaluate them. Each engagement records the specifics in a data-flow document that you can inspect.

A supported workload is one we have tested, operate routinely, and monitor. New workload types are added through the same review and approval process, not by default.

• Content and creative drafting from approved reference material, with human review before anything is published.
• Reporting narratives and analysis preparation from numbers produced by your reporting systems.
• Data preparation for attribution, including deduplication of inquiries across calls, forms, and chat, and matching to CRM records using approved identifiers.
• Transcription or summarization of recorded calls, only where you have enabled recording with the notices your organization requires, and only for the fields approved for the purpose.
• Internal automation that prepares work for a person to approve, as described on our customizable AI page.
• Testing of configurations before deployment, using representative inputs with identifying details removed or replaced.

Workloads outside this list, such as autonomous patient-facing actions or clinical decision support, are not supported and are not planned.

Data enters through defined paths: scheduled exports from your systems, supported API pulls, or uploads by named people. The fields involved are listed in the engagement's data list and approved by your reviewers before the first transfer.

The data list is marketing data: inquiry source, service line of interest, location, contact preference, campaign identifiers, scheduling or admission outcome, and the identifiers needed to match records. Clinical records are not part of a marketing data list. If a workload would need a field that is not approved, we design the workload without it.

Data leaves the environment when a workflow writes a result back to one of your systems or sends an approved output through an external service. Each workflow's plan lists where its outputs go.

Typical destinations are your CRM, your email or messaging platform, your reporting dashboards, and, for campaign measurement, the ad platforms and analytics tools you already use. Outputs go only to the destinations in the plan. We do not use your data to train models without written approval.

Local processing coexists with external services because marketing runs on them. The categories we expect in most engagements are listed below; the specific services are named in your data-flow document.

• Advertising platforms, which receive campaign settings and conversion signals within the limits you approve.
• Analytics and tag management, configured to collect marketing data without sensitive fields.
• Call tracking, which handles number assignment, routing, and, where enabled, recording.
• CRM and marketing automation platforms you operate, which receive records and status updates.
• Email and messaging delivery services for approved sends.
• Cloud services where a specific workload requires them, named in the plan.
• Outside model providers for specific tasks, only where approved, with the data list for that task defined.

We do not describe our setup as local-only. The honest description is that supported workloads run under our control and that every external call is approved and recorded.

Working data for an engagement is retained on our infrastructure for the duration of the engagement and deleted on request or at the end of the engagement, within the period set in the agreement. Logs that support review are retained for the period the agreement specifies and then removed. Backups follow the same schedule.

You can request deletion at any time through your named contact, and we confirm completion in writing. Our data sovereignty page describes retention alongside storage, access, and outside providers in one place for your reviewers.

Infrastructure we own can be unavailable, like any other. The fallback is defined per workflow, in the plan, before launch.

The default is that the workflow pauses and the item routes to a person with a note. Nothing is sent or changed without that step. Where you have approved it for a specific task, a named external service can serve as fallback with the same data limits and the same approval step. We do not fail silently, and we report any fallback use in the next operating check.

A named operator on our team is responsible for the environment. Access is role-based and limited to the people who need it for the engagement, and access is removed when a person leaves the engagement. Monitoring covers availability, errors, and the workflows running on the environment. Every configuration change is logged with who made it and why.

Those controls are part of our AI governance approach: access controls, testing before deployment, human review at defined decision points, and clear accountability. They support responsible execution without promising that technology alone resolves every security or compliance obligation.

Security questionnaires and privacy reviews ask where data is processed, who can access it, which third parties are involved, how long it is kept, and what happens when something fails. The answers above come from the records we keep for each engagement, and we provide them in your review format. Our owned infrastructure page explains why we operate our own systems in the first place.