Bounding volumes are usually computed procedurally. For example, an axis-aligned bounding box can be computed by iterating the vertex set of a mesh and saving the minimum and maximum X, Y and Z coordinates, although there are other volumes such as spheres, oriented boxes, and capsules which can involve more complex algorithms. Because such computations are typically expensive they tend to be done offline, either as part of an export step from the modeling package or as part of a data packing or compilation step during the build of a game.
In some cases, loose bounding volumes (those that do not conform as tightly as possible to the object) are desirable. Typically this is when the volume will not be used for rendering/optimization purposes but instead for design or gameplay mechanics purposes. In such cases the volumes could be created by hand. This would probably be done in a content creation tool, or by marking a phantom primitive in the modeling tool as a bounding volume (note that modeling tools need not have a built-in "mark as bounding volume" operation, as most can tag objects with user-defined values that custom exporter pipelines can process).
There are no industry standards for how and when bounding volumes are computed (or authored, if applicable). Most asset pipelines are proprietary, designed to serve the specific needs of a studio and/or project, and this operation falls under the realm of an asset pipeline task.