Data security is the first question we hear, and the one we most like answering. This page says plainly how your documents are held, who can see them, and what we will put in writing.
Security is a design principle of this platform, not something added to it afterwards. Confidentiality, integrity and availability decide how it is built, run and operated.
Our team has over 50 years of managing corporate IT infrastructure behind them, and the platform is built on that experience. Questions for your security team go to cybersecurity@unseen.id.
On Google Cloud Platform infrastructure in Australia. The core application and customer databases are hosted there. Other residency can be arranged per engagement and is written into the contract.
AES-256 at rest and TLS 1.3 in transit, on a zero-trust approach to data and user access. Cloud security operations systems monitor the platform and its perimeter, and external penetration testing is conducted periodically.
The platform is shared. Segregation is enforced by the permissioning system, which applies access control at row level inside individual tables. Entitlements are resolved at query time and applied to the retrieval layer before the model is invoked, so a query only ever reaches records the requesting user is entitled to.
ISO 27001:2022, certified by BSIGlobal. We hold a SOC 2 Type 1 report. We are pursuing certification against ISO 42001:2023 for AI management systems, and we have self-assessed against NIST SP 800-171. The certificate, Statement of Applicability, report summary and the self-assessment are available on request.
Nominated members of the Unseen team, for analysis and operational support. Their access is logged like anyone else's.
Yes, at infrastructure level and at database level. Backups are encrypted and stored separately from the platform, and no individual, Unseen technical staff included, can reach individual data elements inside a backup.
For the length of the contract, or as otherwise agreed. Data held in backups is retained until the backup set is deleted, typically two years from creation.
Typical availability meets or exceeds 99.0%. The platform runs on Google Cloud Platform infrastructure and scales with user and processing load.
A structured incident management process captures the incident and manages communication to affected stakeholders, with defined escalation and notification paths.
Every interaction is traced and logged, including the requesting user, the query, the data scope retrieved and the output returned. The underlying cloud environment is continuously monitored for security and configuration issues with Rapid7 and Google Security Command Centre. Monitoring is real time, confirmed daily, and reviewed by management at least monthly.
You do. Permissions are granted by your own administration team through the Unseen Admin Portal. We provision the first administrator account, and every account and permission after that is under your control.
Roles are assigned to groups, users inherit the roles of the groups they belong to, and groups are granted access to individual assets or portfolios and the buildings under them.
Yes. Access is granted at the level of individual assets and their buildings, not only whole portfolios, so someone can be entitled to three buildings out of thirty.
With their work email address and a one-time token sent to it, or through your own single sign-on, integrated following OIDC best practice.
Your administration team can generate permission roll-ups and reports from the Admin Portal for audit and review.
No, and it does not depend on the model behaving. A user's entitlements are resolved server-side before the query runs, and the retrieval layer returns only the records that user is permitted to see. The model reasons over that filtered set alone. Records outside the entitlement are excluded before the model runs, so rephrasing cannot surface them.
A control that depends on the model recognising and refusing an improper request is probabilistic. Constraining the query to the user's entitlements before it runs is deterministic. We rely on the deterministic constraint, with input sanitisation, system-prompt hardening and monitoring behind it as defence in depth.
We use a mix of privately hosted models and privately accessed services such as Google Vertex AI, reached over authenticated APIs. Data is not sent to public models.
Not for public model training. Where you approve it, your data is used to test features built for your requirements, so that what the platform does to your data stays verifiable end to end.
Document content is retrieved as data through tools and kept separate from the system's own instructions. Adversarial text embedded in a lease or a valuation report is read as evidence, not as a command.
Request rate limiting and concurrency caps apply at the platform edge, sized above normal working patterns so ordinary analyst work is unaffected. Sustained abnormal volume triggers throttling. These limits apply to queries, not to how much data you ingest or store.
Queries are scope-bound. A request falling outside the defined data and functional boundary is refused rather than attempted, each component is constrained to its own area of expertise, and tracing across every interaction lets us monitor for anomalous behaviour.
Excel and PDF today, with more formats to follow. Where a direct connection is wanted, our APIs can read from your existing back-end databases, so there is no need to stand up a new data store.
Nothing. Upload the documents to the agreed location and our team handles ingestion from there.
No restrictions on file sizes, and we do not charge for storage. Keep as much on the platform as your work requires.
You are welcome to remove any fields you would rather not have ingested.
The platform does not support the ingestion of private data or personally identifiable information. Remove it from the dataset before uploading.