Privacy Policy

Last updated: September 14, 2026

Overview

Model Optimizer helps engineering teams understand and reduce their AWS Bedrock spend. To do that, we read your Bedrock Model Invocation Logging (MIL) data from S3 in your AWS account, calculate cost and usage metrics, and surface optimization recommendations in our web application. This page explains what we collect, how we use it, where it lives, and what choices you have.

We've tried to keep this in plain language. If anything here is unclear or you'd like more detail, email us at hello@modeloptimizer.ai.

Who we are

"Model Optimizer," "we," "us," and "our" refer to the team operating the Model Optimizer service at www.modeloptimizer.ai and the application at app.modeloptimizer.ai. You can reach us with any privacy questions at hello@modeloptimizer.ai.

What we collect

• Account information. When you sign up, we collect your name, email address, and organization. This is used to authenticate you and to associate you with your team's account.
• Billing information. If you upgrade to a paid plan, billing details (card information, billing address) are collected and processed by Stripe. We do not store your full card details on our servers — Stripe handles that. We retain a customer ID, subscription ID, and the resulting invoice/charge metadata so that we can reconcile billing.
• Your AWS Bedrock usage data. Once you connect a data source, we read MIL records from the S3 bucket you point us at. For each Bedrock invocation we ingest, we store fields such as: timestamp, AWS account ID, AWS region, model ID, input/output token counts, calculated cost, request latency, request status, and any error code or message returned by Bedrock.
• Prompt and response content (only if you choose to share it). Bedrock MIL records can include the full prompt and response text. Whether that content reaches us depends on the data mode you select during onboarding (see "Two data modes" below). In Full Analytics Mode we keep it as the Prompt Similarity Index and Prompt Pattern Analysis described there.
• Connection configuration. The IAM role ARN, S3 bucket name, External ID, and data mode you configure for each data source.
• Model provider acknowledgments (Playground). This one is not live yet — it is built and verified in our development environment, and we are describing it here before it ships rather than after. Some models in our Playground come from providers whose own terms allow them to keep what you send for a period, or to have a person review it. When the step goes live, the Playground will show you that provider's terms for the model you picked and ask you to accept them before sending anything, and we will keep a record of the acceptance — the provider-policy acknowledgment. That record holds your organization and member identifiers, the run, the model, its handling mode, the version of the disclosure you accepted and the text of it, and the server time. The provider-policy acknowledgment does not store prompt or response content: the prompt and the response are held separately, under the Playground retention described below, and are never written into it.
• Site usage analytics. We are not currently collecting product-analytics events from our marketing site. Our PostHog integration is disabled: the code is still present in the site but is switched off, so the analytics script is never loaded and no events are sent to it. Events PostHog received while it was active are still held by PostHog until their retention period lapses. Every page does load a Google Tag Manager container from Google's domain — see "Cookies and tracking" below for what that means.
• Email correspondence. If you email us, we receive your message and email address and may retain it for support history.

Two data modes

During onboarding you choose how much MIL content reaches us:

• Full Analytics Mode. We read MIL records directly from your S3 bucket. Those records may include the full prompt and response text, depending on how you've configured Bedrock MIL. If they do, we ingest and store them in two categories. The Prompt Similarity Index holds a similarity signature for each distinct prompt together with a representative sample of the prompt itself — prompt text, not only a fingerprint. Prompt Pattern Analysis holds the representative samples promoted from that index, the usage statistics for each pattern, and the analysis generated from them. That is what powers prompt grouping, task-complexity rating and the model right-sizing recommendations.
• Privacy Mode. You deploy a small Lambda function (the "Bedrock Log Sanitizer") inside your own AWS account using a CloudFormation template we provide. The sanitizer strips the prompt body (input.inputBodyJson) and response body (output.outputBodyJson) from each MIL record before writing the sanitized records to a separate S3 bucket. We only read from that sanitized bucket. The original prompts and responses never leave your account.

Privacy Mode trades some recommendation depth (we can't analyze prompt complexity if we never see the prompts) for stronger data isolation. If your Bedrock usage involves content you cannot share with a third-party processor — PHI, regulated financial data, or anything similar — use Privacy Mode, or do not connect Model Optimizer to that workload at all.

How we connect to your AWS account

We do not ask for or accept AWS access keys. The CloudFormation template you deploy creates an IAM role in your account that trusts our AWS account and is gated by a unique External ID we generate for you. The role's permissions are limited to the S3 actions needed to list and read objects from the bucket you specify (s3:ListBucket, s3:GetBucketLocation, and s3:GetObject on that bucket only). We have no write access, no access to other resources in your account, and you can revoke our access at any time by deleting the CloudFormation stack.

How we use the information

• Operate the service. Authenticate you, render the dashboard, calculate cost and usage metrics, generate optimization recommendations, and aggregate daily summaries.
• Bill you, if you're on a paid plan. Calculate your usage-based charge and report it to Stripe so you can be invoiced.
• Communicate with you. Send transactional email related to your account (sign-in links, billing notifications, connection-failure alerts, security notices) and reply to support emails.
• Improve the product. Debug issues, troubleshoot ingestion failures, and improve the quality of our recommendations.
• Protect the service. Investigate abuse, fraud, and security issues, and comply with applicable law.

We do not sell your data, and we do not use your prompts, responses, or usage data to train machine-learning models.

Where your data lives and how it's protected

• Region. Our infrastructure runs in AWS us-east-1 (N. Virginia). Account data, configuration, and ingested usage records are stored there.
• Encryption in transit. All traffic to our web application, API, and AWS services is over HTTPS/TLS.
• Encryption at rest. Customer data stored in DynamoDB and S3 is encrypted at rest using AWS KMS-managed keys.
• Access control. Internal access to production data is limited to the small operations team that runs the service, and is granted on a need-to-know basis through AWS IAM.
• Point-in-time recovery. Our primary DynamoDB tables have point-in-time recovery enabled to protect against accidental loss.

We do not currently hold SOC 2, ISO 27001, HIPAA, or PCI certifications. If your organization requires any of those, please factor that in before connecting workloads that fall under those regimes.

How long we keep your data

• Bedrock usage records. Ingested usage records are stored for approximately 3 years from the record's timestamp, after which they expire automatically.
• Account and configuration data. Retained for as long as your account is active. If you close your account or delete a data source, we will delete the associated configuration and stop ingesting from it.
• Billing records. Retained as long as needed to meet tax, accounting, and audit obligations.
• Prompt Similarity Index and Prompt Pattern Analysis. Everything in both categories — the similarity signatures, the representative prompt samples, the per-pattern usage statistics and the analysis generated from them — is kept while the data source is connected, and expires automatically three years after the most recent Bedrock call it was derived from — the same three-year clock the underlying usage records run on. Where a record covers a group of similar prompts, that clock runs from the most recent call in the group, so nothing in either category is kept more than three years past real Bedrock activity it describes.
• Playground runs. Runs you save are kept until you delete them or delete the data source they belong to. Unsaved Playground runs are removed automatically after about five days. That five-day limit covers the run record itself. Separately from it, a Playground model call is recorded in the underlying AWS model service's invocation logs for 90 days and in our shared AI-processing layer's operational logs for 30 days, both described in the next item. Playground calls are not added to that layer's response cache or its prompt-pattern store.
• Copies held by our shared AI-processing layer. Responses cached by that layer expire 90 days after they are written. The invocation logs the underlying AWS model service writes — for our own analysis calls and for Playground model calls alike — expire after 90 days. That layer's own operational logs, which record the beginning of each prompt and system prompt — and, on rare failure paths, a full response — are retained for 30 days. Those records carry no customer or data-source identity, so deleting a data source does not purge them early. The two shared prompt stores that layer maintains are different stores from your own Prompt Pattern Analysis above. They no longer receive new analysis, so what they hold is historical, and those records expire 90 days after the last prompt that matched them was seen.
• Email correspondence. Retained for support history; you can ask us to delete specific messages.

Service providers we share data with

We use a small number of third-party services to operate Model Optimizer. Each of them only receives the minimum data necessary to do its job:

• Amazon Web Services (AWS). Our hosting and storage provider. All ingested data, application servers, and email delivery (via Amazon SES) run on AWS.
• Stytch. Handles user authentication and team-membership for our application. Stytch receives your email address and name when you sign up or are invited to a team.
• PostHog. Previously provided product analytics for our marketing site. The integration is disabled and PostHog receives nothing further from us. It still holds the events it received while it was active — page views, clicks on signup prompts, which gated pricing features were used, and, for signed-in visitors, the account email address — until their retention period lapses.
• Stripe. Handles payment processing for paid plans. Stripe receives the billing information you provide at checkout and the usage-based charge amounts we report.
• Calendly. If you book a setup or sales call through a Calendly link we share with you, Calendly receives the contact and scheduling details you submit.
• Google. Every page loads a Google Tag Manager container from Google's domain, so Google receives the request metadata that any web request carries — your IP address, user agent, and the page you requested. The container is the mechanism that would deliver an analytics tag if we published one; it currently holds no tags, so nothing is forwarded through it to any analytics destination.

We may also disclose information if required to do so by law, or to protect the rights, property, or safety of Model Optimizer, our customers, or others.

Cookies and tracking

Analytics on the marketing site. We are not currently collecting product-analytics events from our marketing site at www.modeloptimizer.ai. It previously used PostHog, a product-analytics service; that integration is disabled — the script is not loaded, no events are sent, and nothing new is stored in your browser for it, though storage it placed there before it was disabled stays until you clear your browsing data — and we have not selected a replacement analytics platform. PostHog still holds the events it collected while it was active, as described under "Service providers we share data with" above. Every page does load a Google Tag Manager container from www.googletagmanager.com, which is a request to Google's domain rather than ours, so Google receives your IP address, user agent, and the page you requested. That container currently holds no tags, so it forwards nothing to an analytics destination; before we publish a tag or turn collection back on, we update this page first. Apart from that tag-manager container, page resources — including fonts — are served from our own domain.

Signed-in sessions across our sites. Our application at app.modeloptimizer.ai uses cookies and similar storage as needed to keep you signed in — these are essential to running the application and are not used for advertising or cross-site tracking. If you have an account and are signed in, your session cookie is shared across our own modeloptimizer.ai subdomains so that pages on the marketing site (for example, the Bedrock pricing reference) can show you the signed-in features you're entitled to without a separate login. This never extends beyond our own domain.

Server-side request logs. Separately from the client-side behavior described above, our content delivery network (Amazon CloudFront) writes standard access logs to a private S3 bucket. Each entry records the request timestamp, the requested URL, response status, client IP address, referrer, and user agent. We use these logs for security monitoring and to understand site usage in aggregate. Logs are retained for 90 days and are not shared with any party outside of AWS, our infrastructure provider.

Your choices and rights

• Disconnect at any time. You can delete a data source in the application, which stops further ingestion, and you can delete the CloudFormation stack in your AWS account, which revokes our access entirely.
• Delete your account. Email us at hello@modeloptimizer.ai and we'll delete your account and the associated configuration and usage data. Some records are retained beyond that, as described under "How long we keep your data" above.
• Access and export. If you'd like a copy of the data we hold about you or your organization, email us and we'll work with you to provide it.
• Correct or update. Most account details can be updated directly in the application. For anything else, email us.

Children

Model Optimizer is a business product not directed at children, and we do not knowingly collect personal information from anyone under 16.

Changes to this policy

When we make material changes to this policy we'll update the "Last updated" date above and, for significant changes, notify account owners by email. Continued use of the service after a change means you accept the updated policy.

Contact

Questions about this policy, your data, or how to exercise any of the choices above? Email us at hello@modeloptimizer.ai.