Autopilot Blog — AI Processing and Subprocessors

Effective date: October 14, 2026

This document explains how Autopilot Blog, a service of Octetra, LLC, processes your content with AI models and which third parties are involved. It describes how the service is built and operated. This page accompanies the Autopilot Blog Terms, and the summaries below quote its Agency Pilot sections (Part 3). If you are on the Standard Plan (Part 2) or an Agency Plan (Part 4), the part for your plan differs from the pilot in what it provides, so do not read the summaries below as describing your agreement. This page does not replace your terms. Where this page and your terms differ, your terms govern.

What this page covers. How your content is processed by AI models, and which third parties receive what. It is not a complete data-protection statement. Retention, deletion and breach notification live in your terms and are summarised in Section 11. If you need a data processing agreement, or detail on storage, logging, encryption or who at Octetra can access your instance, ask us and we will put it in writing. Questions: javid@octetra.com.

1. Why this document exists

Section 24 (Data) of the Autopilot Blog Terms, for the Agency Pilot, says we share your data with “the infrastructure and AI providers needed to run the service.” That is true but not specific enough to evaluate. This page is the specific version.

2. The one thing to understand first

Autopilot Blog does not have a single AI provider. Each instance is configured independently, and which model provider handles your content is a property of your instance, not of the product. Two customers on the identical version of the software can have different providers, and therefore different terms governing their content.

We will tell you which configuration your instance uses, and we will tell you before we change it. See Section 5.

3. What data the service handles

Content you or the service create. Topic ideas, research notes, drafts, revisions, published posts, generated images, and the briefs and reports we deliver.

Reference material you supply. Documents you add so the service can write in your voice, including your own published articles when you choose to load them. See Section 7.

Configuration and credentials. Connection details for the systems you authorize, such as your publishing target and analytics properties. Credentials are stored for operation and are not included in the prompts sent to a model provider. One exception, stated because it is the kind of thing you should hear from us rather than discover: if your instance is delegated to an agent runner (Section 5.2) and you have enabled executable hooks, the credentials those hooks act with are sent to the runner alongside the hook instruction.

Performance data. Read-only analytics we pull from accounts you authorize, currently Google Analytics 4 and Google Search Console, used to report on and tune your blog.

4. Where your content goes inside the service

The service runs as a set of jobs, and different jobs see different things. This matters, because it bounds which third parties can ever receive your material.

Research. Generates and investigates topic ideas, and can perform a live web search while doing so. It works from topic and keyword inputs, together with the configuration you write for us: your positioning, audience, strategy and research notes. It does not receive your reference library.

Idea scoring. Ranks candidate topics by demand, intent and competition, and can also perform a live web search while doing so. It does not receive your reference library.

Selection. Chooses which of your reference documents are relevant to a given draft. It sees only document metadata: identifier, type, title, publication date, and a short description. It does not receive document bodies.

Writing. Produces the draft. This is the only job that receives the body text of your reference documents, and only the ones selected for that specific draft. Documents that fit a size budget are sent whole; longer ones are truncated; where more are selected than the budget allows, the remainder are left out. This job performs no web search.

Humanizing. Revises the draft produced by the writing job.

The practical consequence: your reference library reaches the writing job and nothing else. It is never sent to a web-search provider, and it is not used to generate topic ideas.

5. How the AI models are configured

Every instance runs in one of two configurations.

5.1 Direct provider. Your instance holds credentials for a model provider and calls that provider's API itself. In this configuration the provider is known and named, and that provider's commercial terms govern how your content is handled.

Where we use Anthropic's Claude models through the Anthropic API, two published statements apply. From Anthropic's Commercial Terms of Service, Section B (Customer Content): “Anthropic may not train models on Customer Content from Services.” From Anthropic's privacy documentation for commercial products: “By default, we will not use your inputs or outputs from our commercial products (e.g. Claude for Work, Anthropic API, Claude Gov, etc.) to train our models.” The exceptions Anthropic lists require an affirmative act on our side: explicitly reporting feedback or a bug, or otherwise opting in. We do not do either with your content, and we would not begin without telling you first.

Sources, so you can read them rather than rely on our summary:

• https://www.anthropic.com/legal/commercial-terms
• https://privacy.claude.com/en/articles/7996868-is-my-data-used-for-model-training

The service also supports OpenAI-compatible providers, currently OpenRouter, Groq and DeepSeek, and a custom endpoint you or we specify. If your instance uses one, that provider's terms apply instead of Anthropic's, and we will tell you which.

5.2 Delegated to an agent runner. Your instance holds no provider credentials and instead sends model work to a separate execution endpoint, which decides how the request is fulfilled. In this configuration the governing terms are those of whoever operates that runner and whatever provider account it uses. We will identify the runner and its governing terms for your instance on request.

We are drawing this distinction plainly rather than describing the product in general terms, because the two configurations can be governed by genuinely different documents, and the difference is not visible from the outside.

5.3 Which one applies to you. Ask us and we will tell you, in writing, which configuration your instance is on, naming the provider or the runner.

Where a job is delegated to a runner, we can name the runner but not the provider behind it, because that is the runner operator's to state. If you need a named provider for every job, tell us and we will move your instance to a direct-provider configuration.

6. What we can and cannot promise about model providers

We can tell you what our system requests: which job sends what, to which endpoint, under which account. That is a property of our software and we can evidence it.

We cannot independently guarantee what a third party does with a request once it holds it. For that, the provider's own published terms are the authority, which is why Section 5 quotes them and links them rather than paraphrasing.

7. Your published articles as reference material

If you choose to load your published articles so the service can write in your voice:

• The selection is yours. You decide which articles are included, and you can revise or withdraw that list at any time.
• Your library stays in your instance. It is not shared across customers and is not used to produce anyone else's drafts.
• Only the articles selected for a given draft are sent, and only for that draft. Shorter ones are sent whole and longer ones truncated, as described in Section 4. Each carries its title, and its publication date and source URL where we hold them, so a reviewer can see the age of the source.
• There is no automatic newer-wins rule and no automatic flagging of time-sensitive claims. Your review of the list is the control that governs this. We would rather say so than imply a safeguard that does not exist.

8. Other third-party services

Which of these are active depends on your configuration. Ask us and we will tell you which are enabled on your instance.

Tenancy. We operate your instance on servers we control at DigitalOcean. Instances may share a server with other customers rather than running on dedicated hardware. Each instance runs its own database in its own container, on its own private network. No instance's database is reachable from the internet, or from another instance's network. We will tell you, on request, what your instance runs on.

9. Your readers' data

The sections above concern your content and the accounts you authorize. This one concerns the people who visit the blog we publish for you, which for an agency means your clients' visitors.

Our theme loads web fonts from Google. That is our doing rather than a setting you chose, and the consequence is that every visitor to your published blog sends their IP address and user agent to Google in the course of fetching those fonts. If that does not fit your or your clients' privacy posture, tell us and we will serve the fonts ourselves.

Your own analytics are yours. If you set a Google Tag Manager or Google Analytics ID, those tags render on your blog with your identifiers, sending to your properties under your own agreements with Google. We are not a party to that and do not list it among the services we share data with, because it is not ours to share.

We do not otherwise track your readers. The service places no advertising, identity or cross-site tracking on your published blog.

10. Publishing control

The service publishes only to the target you choose, and during a pilot that target is normally a staging environment. Generated posts enter a review queue and publish only after someone on your team approves them. We do not disable that review requirement except on your written instruction. See Section 19 (Publishing Control) of the Autopilot Blog Terms.

11. Retention, deletion, and breach notification

Governed by Section 24 (Data) of the Autopilot Blog Terms, for the Agency Pilot. In summary: you can request permanent deletion at any time and we complete it within 30 days; if you cancel without asking, we delete within 60 days of your final billing period, covering backups within 90 days; and if we discover unauthorized access to your data we notify you within 72 hours of confirming it. Your terms are the binding statement.

12. Changes to this document

We will update this page when our processing changes, and we will change the effective date. If a change affects which provider handles your content, we will tell affected customers directly rather than relying on you to check this page.

13. Contact

javid@octetra.com