
Security and data use
Security, Cloud Data Use & Model Improvement
The cloud service boundaries, data-use controls, and current assurance limits for AEIS Web and AEIS Desktop. No unverified certification or penetration-test claims.
How data is handled
Cloud controls and model-improvement use are explicit.
The same policy boundary applies to AEIS Web and to desktop workflows that use AEIS cloud identity, storage, or AI services.
Cloud-connected Web and Desktop
AEIS Web and AEIS Desktop use AEIS cloud identity, licensing, session control, storage, service coordination, and AI service paths. Desktop workflows can still use licensed local engineering tools or a local inference fallback when a workflow is configured that way.
Default model-improvement setting
After the published effective date, product content handled through AEIS cloud services may be used to improve AEIS models by default unless an organization administrator opts out for the organization. This includes project inputs and outputs, prompts and responses, support content, and product telemetry subject to the exclusions below.
Excluded before dataset use
AEIS excludes credentials, secrets, tokens, authentication and session records, payment data, security and audit records, malware, and content marked restricted. Automated screening places uncertain material in a blocked review state rather than admitting it to a dataset.
Quarantine before approval
Eligible material is screened and held in controlled quarantine. It is not admitted to a training or evaluation dataset until an AEIS reviewer records the required quality and sensitivity decision.
Organization controls
An organization administrator can opt out in AEIS. Opting out immediately stops future model-improvement collection and starts deletion of retained future-use copies, including intake, quarantine, approved copies, and queued jobs. It cannot retroactively remove learning already incorporated into a trained model.
Retention and notice
Quarantine material is retained for up to 30 days. Approved material is retained only until it is retired from the relevant training corpus or the organization opts out. Organization administrators receive email and persistent in-app notice at least 30 days before a default-on policy becomes effective.
Service providers
Named providers, defined roles.
Providers are named by the role they perform. Any provider that receives curated training material is disclosed before that use begins.
Cloudflare
Worker authorization and protected R2 storage.
Supabase
Identity, licensed-session control, database policy, and audit state.
OpenAI
Hosted AI inference when AEIS selects the OpenAI provider for a workflow.
Ollama
Optional local or separately configured OpenAI-compatible inference fallback.
Resend
Organization and service email delivery; notices do not include project content.
Enforced controls
Security boundaries are part of the product.
Controls apply at the public intake, session, service, worker, and engineering-review boundaries.
Public access intake
Workspace access requests use bounded fields and body sizes, Turnstile verification, origin and client-identity checks, idempotency, and rate limits. A project file is not required for the first request.
- Private intake tables and restricted RPCs
- Bounded delivery retries and dead-letter state
- No form contents in public responses
Account and session boundary
Sign-in and session work stay behind the FastAPI service. The browser receives a server-issued HttpOnly session cookie rather than Supabase access or refresh tokens.
- Licensed-email and verification-code checks
- Protected routes excluded from search indexing
- Production origin and trusted-host enforcement
Service deployment boundary
The public Next.js service proxies to a private FastAPI boundary. Production startup fails when required host, session, worker, access-request, or Turnstile configuration is absent.
- Loopback-only FastAPI production binding
- Cloudflare-aware public client identity
- Server-only credentials kept out of browser bundles
Engineering execution boundary
AEIS names whether work runs in the browser or through a Windows worker. SAFE, ETABS, PLAXIS, model assumptions, and final engineering acceptance remain controlled by the qualified project team.
- Visible execution requirements
- Traceable run and output state
- Qualified engineer approval remains mandatory
Shared responsibility
Secure deployment still requires operating discipline.
AEIS secures the service boundary. Your team controls authorized use, source data, licensed tools, worker hosts, and engineering acceptance.
AEIS
- Public intake verification, rate limits, and bounded request handling
- Server-issued sessions without browser-held Supabase tokens
- Private service boundary and production configuration gates
- Visible execution requirements and traceable run state in product workflows
Your team
- Authorized accounts and licensed work emails
- Approved BIM source data and project confidentiality
- External-tool licensing and worker-host protection
- Qualified review of every engineering result before use
AEIS does not claim an unverified security certification, penetration-test result, or compliance attestation on this site. Ask for the controls and deployment scope relevant to your implementation.
Review your security and data-use boundary.
Ask about cloud processing, organization opt-out, retention, providers, or engineering workflow controls.