What We’re Learning From Building Ethen for Both Consumers and Enterprises

The main difference between consumer and enterprise AI products is not what good AI work requires — it is who decides and who owns the data. A person using Ethen for their own projects and a company using Ethen across a team need the same things underneath: work that can be checked, precise approval before consequential actions, honest handling of what the system does not know, memory people can see and control, and a record of what happened. What differs is ownership and defaults. In personal use, the individual decides and owns their data. At work, the organization sets policy, within the law, over work data and work actions. Building for both is teaching us to keep the core identical, make ownership explicit, start every capability with strict defaults, and refuse incentives — like engagement optimization — that would serve one audience at the expense of trust in both. This article shares those lessons.

Key takeaways

• The core is the same. Verification, approvals, honest unknowns, visible memory and records serve both audiences.
• Ownership is the real difference. Who decides, and whose data it is, must be explicit.
• Defaults differ. Simple and private for individuals; restrictive until configured for organizations.
• Building both enforces discipline. Capabilities start strict and loosen deliberately.
• Some incentives are refused. No optimizing for engagement or attachment, in either context.

Why build for both at all?

Many AI companies choose one audience. Consumer products move fast and reach many people; enterprise products move slower and need governance, security reviews and procurement. Serving both is harder than serving one. So why do it?

Because most people's work does not divide neatly. The same person drafts a personal email in the morning and a client proposal in the afternoon. Founders use the same tools for their company and their life. Small teams start as one person and grow into organizations. An AI that knows nothing about how people actually work across those boundaries ends up either too personal for work or too corporate for life.

There is also a practical reason. Much of what makes AI trustworthy — checking work before calling it done, asking before acting, saying "I don't know" — matters equally whether the stakes are a family budget or a company's accounts. Building it once, well, and using it in both contexts is better than building two weaker versions.

Ethen is organized as a family of specialized apps sharing one account, which we describe in Why Ethen Is a Family of Specialized AI Apps. That structure lets the same core serve personal use, small teams and larger organizations without forcing them into one interface.

Lesson 1: the core really is the same

When we list what makes AI work trustworthy, nothing on the list is specific to consumers or enterprises.

Verifiable work. A research summary should show its sources whether it is for a personal medical question or a market analysis.

Precise approvals. Sending a message, paying for something or deleting a file should require a specific decision, whether it is a personal email or a message to a customer.

Honest unknowns. When the AI cannot confirm something, it should say so in both contexts.

Visible, controllable memory. People should be able to see and correct what the AI uses about them, at home and at work.

Records. Both a person and an organization benefit from being able to see what the AI did.

That is a useful discovery, because it means the hardest engineering — the parts that make AI dependable — can be shared. Figure 1 shows how the shared core relates to what differs.

Lesson 2: ownership is the real difference

The hardest questions are about ownership: who decides, and whose data is it? Figure 2 compares individual and organizational use.

Who decides. In personal use, the person decides what the AI may access, what it remembers and what it may do. In organizational use, the organization sets policy for work data and work actions — which providers may be used, what is logged, which actions need approval — and individuals work within it.

Whose data. Data protection law has long distinguished between the party that decides why and how personal data is processed and the party that processes it on their behalf. In a work context, an organization typically decides how its work data is used, and a service provider processes it on the organization's instructions. In personal use, the person is the one whose interests the data serves. Those roles shape what each party may do and must be stated plainly.

Where the line falls. The difficult cases sit at the boundary. A person uses a work account for a personal question. A founder's personal notes include company plans. An employee leaves and wants their personal preferences, but not company data, to go with them. We do not think these have perfect answers, but they need explicit ones: what belongs to whom should never be a surprise.

The principle we hold is that ownership must be explicit and visible, and that purposes — using data to answer a request, storing it, using it to improve systems — are separate and granted separately. Ethen Research Lab's Rights as Infrastructure research note argues for treating these purposes as properties that travel with data, rather than as policies written somewhere else. Our position on memory and training for individuals is in Why User-Controlled AI Memory Matters.

Lesson 3: defaults matter more than features

Individuals and organizations need different defaults even when the features are the same.

For individuals, defaults should be simple and private. Most people will never open a settings page. The system should behave sensibly without configuration: minimal data kept, clear prompts before consequential actions, and an easy way to see and delete what is remembered.

For organizations, defaults should be restrictive until configured. An organization adopting AI should start with narrow permissions, logging that does not retain content unless chosen, and approvals for consequential actions — then loosen deliberately as it understands its needs. Ethen's documented enterprise controls follow this pattern, with logging that records metadata only by default and controls that fail closed. See Why Enterprise AI Needs More Than SSO and Admin Controls.

The common thread is that defaults encode a judgment about who bears the risk of a mistake. For an individual, it is themselves. For an organization, it is the organization, its customers and its employees. Defaults should protect whoever bears that risk.

Lesson 4: building for both enforces discipline

Serving both audiences has an unexpected benefit: it makes every capability start strict.

A capability built only for consumers might launch with broad permissions and fix governance later. A capability built only for enterprises might launch with heavy configuration that individuals would never use. Building for both pushes toward a pattern that works for each, shown in Figure 3.

Build with strict defaults: narrow authority and approvals on. Prove the capability in one context, with evidence from real tasks. Adapt ownership and defaults for the other audience. Release with the same core and different settings.

This is slower than launching everywhere at once. It also means that a capability has shown it works before it reaches the audience with the most at stake.

Lesson 5: some incentives must be refused

Consumer technology has a well-known temptation: optimize for engagement. Products that maximize time spent, messages exchanged or emotional attachment often grow fastest. For an AI assistant, that temptation takes specific forms — flattery, artificial warmth, encouraging dependence, inventing reasons to keep talking.

We have decided not to optimize for those things, in either context. The direction we have described for personal use, in What We Want My Ethen to Feel Like, is explicit that the goal is finished work and user control, not attachment or time spent. Serving enterprises reinforces the decision: an organization will not trust an AI that is designed to keep its employees talking rather than working.

Refusing those incentives has a cost, especially in consumer growth. We think trust is worth more.

Lesson 6: small teams sit in the middle

Small teams are where personal and organizational use meet most visibly. A founder starts alone, with personal projects. Their first hires join shared projects. Eventually, an administrator sets policies. The transition should add controls rather than force a move to a different system. We describe that path in How We're Thinking About AI for Founders and Small Teams.

Designing for that transition has shaped how we think about both ends. Personal projects need to be shareable without losing their history. Organizational controls need to be addable after the fact without breaking what people already rely on. Ownership has to be clear at every stage.

Lesson 7: ideas travel in both directions

We expected enterprise requirements to flow down into personal use. They do: precise approvals, evidence records and fail-closed controls all began as governance ideas and turn out to be just as valuable for an individual whose AI is about to send an email on their behalf.

What surprised us is how much flows the other way. Personal use is unforgiving about complexity. If a control is confusing, individuals simply stop using the feature. That pressure produces simpler approval screens, clearer explanations of what the AI can see, and memory controls that anyone can understand — all of which make enterprise deployments easier to roll out and easier for employees to trust. An administrator's policy is only as effective as the employee's understanding of it.

A worked example: one capability, two contexts

The following example is illustrative. Consider memory: the AI remembering useful facts across conversations.

In personal use, memory belongs to the person. They can see what is remembered, correct it and delete it. Nothing they share is used to improve models unless they choose that purpose separately. Memory is on with sensible limits, because most people will not configure it.

In organizational use, memory is scoped to projects and respects permissions: a fact learned in one project is not surfaced to someone without access to that project. The organization decides whether work memory is enabled and how long it is kept. Employees can still see what the AI is using in their own work, so they are never surprised.

The underlying capability — remembering, retrieving, showing and forgetting — is the same. The owner, the scope and the defaults are different. That is the pattern we try to follow for every capability. We describe the memory principles in more detail in How We're Rethinking AI Memory Across Ethen.

What we have not solved

Several questions remain open, and we would rather name them than imply otherwise.

Mixed accounts. How should personal and work contexts coexist for one person without data leaking in either direction?

Portability. When a person leaves an organization, which preferences and personal data should travel with them, and how is work data reliably left behind?

Consent at work. Employees using AI at work have interests of their own. Organizational policy should not mean employees have no visibility into what the AI does with their work.

Different speeds. Consumers expect new capabilities quickly; enterprises expect stability and advance notice. Serving both means separate release paces for the same core.

Tradeoffs and limitations

Serving both is slower. Strict defaults and staged releases take longer than launching to one audience.

Some features fit only one audience. Not everything should be shared; some enterprise controls would only confuse individuals, and some personal features do not belong at work.

Ownership rules depend on law and contracts. The principles here do not replace legal agreements, which govern the actual relationship.

This is a reflection on direction. It describes how we are thinking and building, not a list of shipped features or plans.

FAQ

Can one AI product serve both consumers and enterprises? Yes, if the core — verification, approvals, honest unknowns, visible memory and records — is shared, and ownership and defaults are clearly separated for each context.

Who controls my data in a work AI account? Typically the organization decides how work data is used, within the law and its agreements, and the service provider processes it on the organization's instructions. The details depend on the agreement.

How is enterprise AI different from consumer AI? Mainly in who decides, who owns the data, which defaults apply and how much governance is needed — not in what makes AI work trustworthy.

Does Ethen optimize for engagement? No. Ethen's direction is to optimize for finished work and user control, not time spent or attachment.

What happens to personal preferences when someone leaves an organization? That is one of the open questions we are working through; the principle is that what belongs to whom should be explicit.

Related reading

• What We Want My Ethen to Feel Like
• Why Enterprise AI Needs More Than SSO and Admin Controls
• How We're Thinking About AI for Founders and Small Teams
• Why User-Controlled AI Memory Matters
• Why Ethen Is a Family of Specialized AI Apps

References

1. Regulation (EU) 2016/679 (General Data Protection Regulation), Article 4 (definitions of controller and processor). https://eur-lex.europa.eu/eli/reg/2016/679/oj
2. National Institute of Standards and Technology (2020). NIST Privacy Framework: A Tool for Improving Privacy Through Enterprise Risk Management, Version 1.0. https://doi.org/10.6028/NIST.CSWP.01162020
3. Ethen Research Lab (2026). Rights as Infrastructure: Building AI Datasets That Know How They May Be Used. Research note. https://upcube.ai/resources/research/rights-as-infrastructure
4. Ethen Docs. Enterprise controls. https://upcube.ai/docs/enterprise/enterprise-controls