A build process is likely to be linked to code changes, such as when committing a set of changes into source control, or merging changes into a main branch.
Builds typically take care of anything which should be consistent across all environments, or where there is no meaningful value in repeating per-environment; for example, static code analysis (lint), coding style checks, and anything else which is specific to the code. A build process might also generate some kind of artefact such as a zip/archive, that archive may be published upto an artefact registry somewhere, with version number too.
Deployment happens per-environment, ideally with minimal variation such as environment-specific configuration parameters and the target resources. For example, it may be useful to deploy into an ephemeral environment for development testing, then some other test environments for QA or integration testing, and finally for at least one production environment (possibly more than one if the strategy involves a passive failover environment, which should obviously be identical to the active production environment)
The difference boils down to looking at each task performed in the process and asking whether that task should happen just once when the code is committed and/or merged, or whether the task should happen every time the code or artefact is deployed, and applied to each target environment.